Restore npm 6 ability to install one package

[dandv]

No description provided.

[ljharb]

In a few projects, I have scripts to explicitly install and uninstall single packages, for the purposes of testing different combinations. For example, enzyme needs to test on a number of combinations of react, react-dom, and a few other packages - but every time I install one of them, other unrelated changes happen to the package tree.

[isaacs]

Is this solved by npm i --workspace=foo, which links the foo workspace and only installs its portion of the dependency graph?

It wouldn't be too hard to apply a similar filter to non-workspace package names, now that Arborist.reify can do this for workspaces. Just would need to figure out the best way to express it in the API surface.

[isaacs]

Adding context here:

This was only the behavior in npm v6 if a package-lock.json file is not present. Otherwise, it'll still install everything in the lockfile.

npm v7 is by design more consistent in its behavior when a lockfile is present vs when it is not.

If we are going to add this, it will have to be an opt-in feature. Breaking the default (which was the default in v6, since lockfiles were created by default in v6) would be too disruptive. Making npm v7 behave differently based on the presence of a lockfile (beyond the difference of "using that as a starting point for the idealTree") is not something we're going to want to do.

All that said, it won't be hard to do. Just need to figure out the UX for which flags to use, how to opt in, etc., and then build up the set of filterNodes in Arborist.reify()

[darcyclarke]

I feel like this will be succeeded by the npm add RFC @ruyadorno is going to write (ref. #395) - If I'm wrong let me know, but we don't have any immediate action items to introduce a net-new flag to do this vs. implementing add in a way that unlocks this again.

[kgryte]

In projects that I work on, we'd also like to be able to install only one package (or a subset of packages) without needing to install the whole dependency tree as suggested in a package.json file.

Similar to @ljharb, we want to be able to dynamically uninstall and install dependencies for testing, benchmarking, etc. Not being able to do so (as in npm v6 in the absence of a package-lock.json file) makes npm v7 unusable for us.

[cbn-falias]

Another usecase:
A very simple job should check if all files of a Pull Request are correctly formatted with Prettier. So I only need this single package and nothing else.
The prettier package is installed in some seconds while installing all the packages takes over one minute (and eats up precious processing time).

[bnb]

@cbn-falias would npm exec prettier not be a better solution in that case?

[louh]

I have a Node.js script that will require packages that it needs, so I'd like to install just those packages beforehand in test environments. I don't think I can run npm exec on a script and have it dynamically fetch the packages I require.

[ljharb]

@louh you can run npm exec --yes in a script and have it dynamically fetch the packages, assuming it has internet access.

[cbn-falias]

@bnb Yes this would also work but I don't see a way to use it with configurations from package.json. (without writing my own shell-script or similar)

• Use version defined in package.json
• Run a script defined in scripts

[bnb]

@cbn-falias I can understand that use case, but I don't know how this would solve that problem as proposed - you'd still need to get the version from the package.json if you passed --only to ensure you don't overwrite the package's version the way npm would normally when it installs a module.

[kgryte]

Another use case we have is that we periodically need to investigate issues in older Node.js versions which are not officially supported. Various dependencies may have dropped support for such versions, so we've taken to maintaining a set of config files listing versions of those dependencies which are compatible with the older Node.js versions. We then have scripts which read those config files and selectively try to install those dependencies so that we can run in older Node.js versions.

With npm v7, we have to introduce workarounds, such as temporarily copying and overwriting the main package.json which is not desirable. Ideally, we should be able to install, uninstall, and reinstall without needing to touch the package meta data which is published to the npm package registry.

[aleen42]

Any progress?

[cbn-falias]

I ended up extracting the version with a powershell-script and then calling it this way:

npm exec --package=$(prettierXmlPckg) --package=$(prettierPckg) --call="npm run formatter-list-diff"

// $(prettierXmlPckg) -> "@prettier/plugin-xml@1.0.2"
// $(prettierPckg) -> "prettier@2.3.2"

[bnb]

@darcyclarke (when you're back from vacation): perhaps worth putting this on the agenda again?

[ljharb]

Yes please; it continues to be a massive annoyance and inconvenience to be unable to have an atomic command do a thing atomically.

[nielspruis]

Is there any update on how this feature will be implemented?

[darcyclarke]

No detail given but we have a tracking issue right now for v9 here: npm/statusboard#464

At a high-level though (from previous discussions) I believe we'd start warning when npm install <pkg> is used (vs. npm add <pkg>) & then we'd likely start remove that feature in v9 & have npm add be a completely separate command (as right now it's an alias to install).

[ljharb]

@darcyclarke hopefully we'd add npm add pkg before warning on npm install pkg?

[ljharb]

although i'm not clear on why npm install pkg wouldn't be Just Fine, considering that's how it always worked prior to npm 7?