Is there a way to pass the --no-optional parameter through to npm when using pm2 install?
In an environment with restricted outgoing traffic pm2 install pm2-fluentd hangs for a while until it times out while attempting to install the optional pm2 dependency:
"gkt": "https://tgz.pm2.io/gkt-1.0.0.tgz"
In the same environment npm install --no-optional pm2-fluentd succeeds quickly, however running this prior to pm2 install does not avoid waiting for the timeout. Being able to pass --no-optional would allow me to install modules in seconds rather than 5 minutes. Is there a way to accomplish this, or will PM2 require an enhancement?
This is documented in multiple closed issues at the PM2 GitHub, including #3444 where the maintainer explains the web URL is intentionally used to gather download metrics, and there is no plan to remove it.
A potential workaround is described in #2507. Here's a version modified for the pm2-fluentd plugin:
git clone https://github.com/bunnyyiu/pm2-fluentd.git && cd pm2-fluentd && pm2 install .
It's probably wise to fork the git repo, and use your own copy, if you need this for production use.
Related
I'm sure others have this workflow, so I must be missing something here.
How does one go about developing a new version of a package, linking it to test in another app, and then installing another (unrelated) package?
What I've done:
Run git clone git#package-to-update && cd package-to-update.
Edit package, update package-to-update/package.json version to 2.0.0.
Update my-app/package.json to use package-to-update#2.0.0.
cd package-to-update && npm link && cd my-appp && npm link package-to-update.
Test out my-app, see that package-to-update#2.0.0 resolves the issue, have a small party.
Push to package-to-update's upstream, create a merge request, and wait for maintainers to merge in my changes.
Use my local, linked version in the meantime as it's required for the feature I'm working on.
Notice I need another package other-unrelated-package in my-app.
Run cd my-app && npm install other-unrelated-package.
NPM fails because it's trying to pull package-to-update#2.0.0, which is not yet published.
Cry.
Is the only option here to run the following process every time you want to npm install?
Downgrade package-to-update in my-app/package.json.
Run npm install other-package.
Run npm link package-to-update.
Upgrade package-to-update in my-app/package.json".
I generally only use npm link for development. If I want to use a local version and not have to deal with re-linking, I install it by path rather than by version.
npm install /file/path/to/your/module
Then you'll end up with a file: URL like this in your package.json:
"slug": "file:../../slug"
Subsequent npm install won't search the registry in that case. (Since it will avoid the registry on future npm install runs, it also means you need to remember to change it back to the registry when the version with your patch is released!)
I haven't tested, but this method may require that you only care about it as an immediate dependency and not a dependency of another dependency. Based on your workflow above, that seems to be the case, but mentioning it here for other folks.
Let's say you're running this command:
npx gulp
npx will search for gulp within node_modules/.bin, and if it doesn't find it there, it will use a central cache. If it is missing, npx will install it.
How do I clear the central cache to force npx to reinstall gulp in this case?
On macOS (and likely Linux) it's ~/.npm/_npx, you can drop it with:
rm -rf ~/.npm/_npx
On Windows it should be %LocalAppData%/npm-cache/_npx
Either way, you can find npm’s cache by running npm config get cache and then finding an npx folder in there.
I needed to do this, due to an error in create-react-app saying 'We no longer support global installation of Create React App.' despite there being no global install. It was stuck in the npx cache, and I removed it like this
npx clear-npx-cache
Our developers pull all of their npm dependencies via an artifactory proxy. The artifactory setup uses a virtual repository that consists of a local npm repository and a remote npm repository.
When developers perform an npm install, the process is slow and often hangs at
fetchMetadata -> network
Any ideas on tracing the source of this issue?
Does artifactory provide a 'trace' api for npm resources, similar to what they have for maven dependencies here maven trace?
Would re-indexing the virtual repository on artifactory help?
Struggled with the same thing. By adding the debug flag when running install helped me. I don't know why, might be some race condition or to many half open connections or something else. When the debug flag is added each step takes a fraction of a second longer to complete, and that seems to be enough. Here's an example for a local package:
npm install -d
or a longer example:
sudo npm install -g -ddd eslint-cli
The number of d's tells npm how verbose debug you want. More d's means more info and longer time to execute. One d did it for me, but my laptop is slow to begin with.
My project references mocha, phantomjs, etc, which takes a lot of time to download during npm install. This is not a problem in my local machine because I only download them once and can use them forever unless I decide to manually upgrade them.
However, in my CI machine, my jenkins server need to download them every time that I did a git commit and git push to do the testing and deploy.
So can I just speed up that process by set the npm not to download these slow packages from the remote server? Rather, install them from local cache or not to install them if I installed them globally?
Anyone knows how to configure that?
I found some packages that might be helpful
npm-install-changed will run npm install only if the contents of package.json's devDependencies and dependencies were changed, note that it assumes that node_modules persists across different builds which might not be helpful if your CI server always start from scratch
npm-install-cache runs npm install and then copies your current node_modules folder (to somewhere in \tmp), if you call the script again it will verify any changes to package.json (instead of changes done on devDependencies or dependencies), if it didn't change then it will copy the node_modules folder stored in \tmp, the only limitation I see is that it's not cross platform and that the cache folder is \tmp which is erased on reboot (or maybe even when a is process finished!)
The second package might not work as it is but it seems like a good place to start :)
You can specify all of the packages you want to use locally in devDependencies in package.json, and then running npm install -d will install those instead of the main dependencies.
I have just installed Homebrew and then I have installed Node (via $ brew install node). When node was installed, npm was automatically installed too (why?).
anyway, now when I install any package from npm, for example $ npm install -g express - it is installed in two locations:
Users/myuser/.npm/express and usr/local/lib/node_modules/express
$ which express retrieves me usr/local/bin/express which refers to usr/local/lib/node_modules/express. I think it's ok that it's installed inside usr/local/lib/node_modules/.. because I used -g flag; but why it is also installed under my own user (Users/myuser/.npm)?
In addition, how does the terminal know about express command? I didn't define any .bash_profile file. how does it know to go to usr/local/bin/$PATH?
Node installs NPM also because Node without NPM wouldn't be Node! :)
NPM is all about a succesful registry. You wouldn't go much further without it.
~/.npm is a cache for all packages - so this actually isn't an installation. As you may know about caches, this is just to avoid re-downloading things over time.
Also, this is configurable via the cache config.
Finally, the last location - usr/local/lib/node_modules is the actual global installation of Express.