npm v5
: npm install
auto-prunes?
#16853
Comments
|
Actually scratch that; it's still auto-pruning even with |
NPM 5 started to erase symlinks meant to polyfill absolute imports. This is very undesirable for me. |
(ping, just because i have no idea when npmbot might annihilate my issue) |
We're closing this support issue as it has gone three days without activity. The npm CLI team itself does not provide support via this issue tracker, but we are happy when users help each other here. In our experience once a support issue goes dormant it's unlikely to get further activity. If you're still having problems, you may be better served by joining package.community and asking your question there. For more information about our new issue aging policies and why we've instituted them please see our blog post. |
This is still an issue... :/ |
sigh. it'd be great if this could be reopened; auto-pruning is pretty destructive behavior. ping @KenanY |
any word on reopening this? I just got bitten by this. Will settle for a |
I can see the motivation for wanting things pruned more frequently to prevent accidentally depending on things that aren't listed in the dependencies. But this is particularly nasty in combination with:
|
@ScottFreeCode exactly
If But npm behaves like it's the only owner of node_modules. But it's no longer the case after so many years of manually patching NPM and Node defects. There are tools, development approaches, deployment strategies and whatever else based on the |
@KenanY any chance this could be reopened? It's still a serious issue. |
Not sure if this should be labelled |
Thanks I'd say it's both :-) "bug" because it doesn't account for symlinks and other pre-existing items in node_modules (not sure if it handles bundledDependencies); "feature request" to disable the behavior. |
I am personally fine if you keep new auto-prune but fire |
This behavior turns |
Personally, I'd like to run |
Having this 'feature' completely defeats the purpose of the Here's an example where auto-pruning is destructive: I have a package that has run-scripts that rely on a couple of external packages. These packages require on-install compiling from source and therefore take a long time to install. The scripts that depend on those external packages only rarely need to be run only in dev env (e.g. once in a few months). So in order to avoid 10-min installs on every CI run I removed these packages from Also, symlink'd packages seem to always break some how because of auto-pruning (I know it's because of auto-pruning because I forked npm and removed the auto-pruning feature and that has fixed the issue, for me at least). |
@ScottFreeCode you can just add a |
Right, or a The larger point being: pruning in a manner that's actually helpful (to ensure that I don't publish something that's depending on things I left out of |
Honestly... I don't love that? The thing with this feature is, it feels to me like npm is overstepping its bounds. It's true that npm is the de facto way of maintaining your node_modules folder, but it's still node_modules, not npm_modules. I feel like npm should respect that it might not be the only thing touching your node_modules folder, at least by default. That said, it seems you could flip your suggestion and npm could mark dependencies as having been npm-installed, which gives you the same information (logically negated) automagically. |
However, in some cases a third-party tool (ex: Lerna) is using the NPM client to install packages, so all packages in So the issue is not only what to do with code in
I think @substack's PR (#18921) is a nice solution to this, but what were you thinking? |
I like #18921 but the default should be to not prune. If you want to prune then you should add it in your configuration or add the flag. No package manager in existence uninstalls (at least a good one) without warning by default (or at least asking "Are you sure you want me to do this?") |
i degrade npm version to 4.x . this problem is so boring. |
I can't believe this hasn't been addressed...is this the demise of npm? Why would anyone ever want a tool to make changes that were not requested by the command issued (with no way to prevent it)? Seems like something Microsoft would do! And why when I install a package that has zero dependencies do I get a message that says 100+ packages were added, removed and updated? My package-lock file shows only 2 changes (the package I installed and not sure about the other, which was a dependency of an unrelated package). I've never installed any packages outside of npm in this project repo. Example:
|
@iarna is there documentation anywhere about this change? |
@iarna that would be better than nothing. I still strongly dislike this feature and would really like to know what the thinking behind this was. Sad! |
PR #18921 would also fix the issue for me and my teams.
I could live with this. But isn't it just a way to whitelist things in you I would then suggest calling it differently, as it will be abused to do things with not-manually jobs as well ;) My suggestion: |
Here a small test-script.
|
@junkert i tried the changes from the commit you mentioned, but it didn't seem to help |
This thread is now almost 7 months old. I think the participants have clearly outlined the problem, identified the root cause, and have suggested several workable solutions, including a PR. I think it would be helpful if a core contributor could chime in and, at the very least, provide some indication of NPM's disposition here; what are your thoughts, what do you intend to do or not do, and what is the approximate timeline. This will help the people affected determine what their best course of action will be. Thank you. |
@iarna (I don't know who else to address/summon) Could you please provide feedback, why this isn't accepted? Some input would be tremendously helpful. |
@cmg-dev Thank you for verifying. You are correct it does not fix the issue. What happened to my original post? |
I don't understand why now under the hood |
Looks like this might have been resolved in See BIG FIXES TO PRUNING section. Specifically, these two commits: 8279515 3b305ee. |
Do not install |
For anyone coming here from Cordova, I can confirm that |
AHHHH YAAAASSS. Its fixed. Finally, npm leaves my poor Using Disable package lock globally:
|
This is still an issue with npm@6.0.0, one symptom being that Just discovered the work-around by @goldhand to disable package-lock globally, which prevents symlinked modules from being deleted or replaced by modules from the registry. Finally I can get back to a saner workflow with Still not a real solution though, and I hope this issue gets the attention it needs. |
See npm/rfcs#3 for the link problem. |
In enzyme, we need to support multiple react versions, so we don't depend directly on
react
. Instead, we use the linked run-scripts in CI to install the version under test with--no-save
, to avoid modifyingpackage.json
, and then runnpm install
.It appears that when something is installed to disk, but not in
package.json
,npm install
now erases it. This doesn't appear in any documentation I've seen.Is this intentional? If so, how can I bypass it for these run-scripts'
npm install
command?The text was updated successfully, but these errors were encountered: