For convenience, many npm based development instruct users to install globally. It makes sense if the tool is used to initiate/create a project, but many such modules are also used with an existing projects. These should installed as local (project) dependencies, which have several advantages: tools The version in use is managed alongside other dependencies, keeping the team on the same page. This is especially important for build tools, used to produce a release. Following this practice could improve the reproducibility of builds, which in turn makes and troubleshooting easier and more reliable. deployment The number of steps needed for new developers to get up and running is reduced, as all of the necessary tools are installed along with the other project dependencies. Multiple versions of a module can be used on the same computer, for example when working on multiple projects which use the tool but may not be upgraded at the same time. A small barrier to this practice is that local dependencies are not directly executable as they binaries live within the project folder. One fix is to add the projects folder to PATH, but don’t do this. For one, it would need to be done by every developer needing to use the command. node_modules/.bin Another option is to add a script to to act as a runner. For example, to make available as a command in your project, install as a project dependency (using )and add script entry to act as a runner for your module: package.json exp --dev # in package.json:"scripts": {"exp": "exp"...} The module will now be installed along with other modules during the installation step, and, thanks to argument forwarding developers can run any subcommand using npm: exp $ npm run exp -- build:ios$ npm run exp -- build:status$ npm run exp -- publish If using yarn, there is no need to add the script entry. Yarn automatically searches for binaries in and uses them if present. It also does not need for argument forwarding: node_modules/.bin -- $ yarn exp build:ios$ yarn exp build:status$ yarn exp publish It may still be useful to add script entries as shortcuts to common commands: # in package.json:"scripts": {"publish: "exp publish"...} # usage$ npm run publish$ yarn publish As pointed out by , another option is now available, , which is installed alongside npm as of npm 5.2.0. Invoking commands with instead of will automatically check for and, if present, run the local dependency: Kevin Kipp npx $ npx $ npm $ npm install --save-dev exp$ npx exp publish Just like yarn, local dependencies are preferred over a global versions of the same modules. Npx, however, goes a step further by automatically installing packages invoked which are not installed either locally or globally. In my opinion this feature will inevitably cause some confusion, surprises, and errors and as such is regrettable. I’m glad to see this practice of installing everything as a local dependency is finally being embraced and supported by the community. Given the advantages I look forward to this being standard practice. It will take time for it to catch on so if you are a project maintainer with a project which instructs users to install globally, please consider changing the instructions to use a local dependency invoked via npx or yarn.

Alongside

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Npm globals as local dependencies

Too Long; Didn't Read

Company Mentioned

Drew Goodwin

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Npm globals as local dependencies

Too Long; Didn't Read

Company Mentioned

Drew Goodwin

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES