NPM scripts - they automatically add "./node_modules/.bin" to your PATH when they are executed, so if you have mocha installed, for example, your NPM script can just be ..."test": "mocha ..."...
NPX - use npx to run scripts in "./node_modules/.bin": npx mocha ... for one-off commands; if NPX cannot find the binary there, it will temporarily download it!
npx create-react-app is awesome
npm ci - look it up it's pretty cool
Use "devDependencies", and use it correctly!
Use the "prepack" hook to run tests & build before your module is built!
"npm pack" will build the *.tgz that NPM stores on their public registry. In many ways this is akin to Java WAR files, without all of the dependencies. You can then put this *.tgz on your server and do an "npm install my-package-0.0.1.tgz"
"bundleDependencies" - worth knowing about (also a tool to use with it is: bundle-deps; run with "npx bundle-deps")
One of my pet-peeves is when a package is globally installed when it should be a devDependencies within a project. For example, if you use the TypeScript compiler in a project, "typescript" is a "devDependency"; do not make installing it globally a requirement. This lets different projects depend on different versions of the typescript compiler. It also makes it so that somebody can download your project and run a build without having to install additional dependencies. This goes for gulp, etc.
npm link - useful if you depend on a development version of a package that only exists on your local machine
npm install /path/to/file - alternative way to accomplish the above point: recent versions of NPM just create a symlink! so you can edit the linked project live and have updates just like you would expect
npm audit - available in >=v6.x - runs a security audit on your dependencies
npm info - want to see what version of a package is the latest? Run npm info express dist-tags
Oh, and don't forget that an .npmrc file local to your project overrides a global .npmrc file: useful for CI servers (store a .npmrc file with your project)!
Another tip is that a separate repository (and credentials) can be configured per scope as well (credit Guillaume Martigny for mentioning scoped modules first below).
This can be useful if you have some private modules in a private repository but do not wish to proxy all requests for public modules through it as well.
I also agree npm link is very useful if working on multiple modules and testing fixes.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
..."test": "mocha ..."...npx mocha ...for one-off commands; if NPX cannot find the binary there, it will temporarily download it!npx create-react-appis awesomeOne of my pet-peeves is when a package is globally installed when it should be a devDependencies within a project. For example, if you use the TypeScript compiler in a project, "typescript" is a "devDependency"; do not make installing it globally a requirement. This lets different projects depend on different versions of the typescript compiler. It also makes it so that somebody can download your project and run a build without having to install additional dependencies. This goes for gulp, etc.
I also forgot a few:
npm info express dist-tagsNPM greater than version 5 is pretty amazing. Earlier versions, not so much. I would recommend yarn if you are stuck with earlier versions of NPM.
Oh, and don't forget that an
.npmrcfile local to your project overrides a global.npmrcfile: useful for CI servers (store a.npmrcfile with your project)!Good point on the project specific
.npmrc.Another tip is that a separate repository (and credentials) can be configured per scope as well (credit Guillaume Martigny for mentioning scoped modules first below).
This can be useful if you have some private modules in a private repository but do not wish to proxy all requests for public modules through it as well.
I also agree npm link is very useful if working on multiple modules and testing fixes.