3 ms·

You're going to have to wipe out package-lock.json or whatever your lockfile is and recompute from scratch. I tend to squirrel away a backup just in case whenev

You're going to have to wipe out package-lock.json or whatever your lockfile is and recompute from scratch. I tend to squirrel away a backup just in case whenever I touch JS dependencies because I've been bitten by yarn/npm/pnpm bs too many times. Also make sure you wipeout all your node_modules, plus your yarn/pnpm cache. Technically, you should only do dependency manipulation sith p?npm|yarn add|remove, to get lockfile recalculation, but depending on version of those tools there are so many quirks you have to watch out for. I always approach any library upgrade as a potential disaster that'll result in me having to nuke my entire node setup for that project and rebuild it from the ground up or last known good state. I never had the kinds of problems I have with JS with any other bloody languages and their respective build tools.

kavaruka 4y ago
This is an old issue; the ecosystem has changed. Now, using the "engine" and "packageManager" properties in "package.json", you can bind your project to a particular runtime version and package manager.
pwdisswordfish9 4y ago
> I never had the kinds of problems I have with JS with any other bloody languages and their respective build tools. lmao
- salawat 4y ago
  The tools in question are npm (Node Package Manager) pnpm being a modified version thereof that adds a compression/content addressible store mechanism to speed things up in a development configuration. Or Yarn ...which is yet another dependency management solution cum build tool, which is Maven/Gradle like. Depending on version though there are so many quirks. Both are "staples" of any enterprise scale project I've run into. I don't have an issue with nodeJS or JS per se. It's the ecosystem and enterprise tooling. I still cannot for certain say those damn build tools don't muck things up in horribly subtle ways, and the experience of debugging the average horrible nest of every dependency known to man has comsumed entirely too much of my life, and the experience overcoming that learning curve I still can't say with confidence wasn't somewhat deleterious to my personal sanity. I can do it trivially now; and I can appreciate the things you can build with it when doing it correctly. The depth of hole you can quickly end up in though is not to be underestimated. That and nigh every JS developer I've run into who says they are proficient knows nothing about really debugging it, or hasn't read the core library docs and really means they can use one framework or another. ...Bar like 3. Who you never want to bother, because they are usually handling issues way more important/wide-ranging that warrant their attention than hand-holding you through learning how it actually works.
  - pwdisswordfish9 4y ago
    If you "don't have an issue" with JavaScript but you think the tools you're using are bad because of the "depth of hole you can quickly end up in though is not to be underestimated", then perhaps you should reconsider your decision to continue using them when you're writing JS and why you ever thought they were necessary. None of those things (package-lock.json, node_modules, or p?npm|yarn) actually come from ECMA-262...
ElectricalUnion 4y ago
> I've been bitten by (...) pnpm bs too many times. I'm surprised, the only node package manager that has any semblance of sanity is pnpm. No flattening BS. Not randomly adding extraneous undeclared dependencies on the dependency tree. Not allowing random dependencies to depend on extraneous undeclared dependencies on the dependency tree. Of course, then you find out that in the real life people actually use other package managers, and depend on non-deterministic, package flattening behavior and extraneous undeclared dependencies requiring extraneous undeclared dependencies...

kavaruka 4y ago

This is an old issue; the ecosystem has changed. Now, using the "engine" and "packageManager" properties in "package.json", you can bind your project to a particular runtime version and package manager.

pwdisswordfish9 4y ago

> I never had the kinds of problems I have with JS with any other bloody languages and their respective build tools. lmao

salawat 4y ago
The tools in question are npm (Node Package Manager) pnpm being a modified version thereof that adds a compression/content addressible store mechanism to speed things up in a development configuration. Or Yarn ...which is yet another dependency management solution cum build tool, which is Maven/Gradle like. Depending on version though there are so many quirks. Both are "staples" of any enterprise scale project I've run into. I don't have an issue with nodeJS or JS per se. It's the ecosystem and enterprise tooling. I still cannot for certain say those damn build tools don't muck things up in horribly subtle ways, and the experience of debugging the average horrible nest of every dependency known to man has comsumed entirely too much of my life, and the experience overcoming that learning curve I still can't say with confidence wasn't somewhat deleterious to my personal sanity. I can do it trivially now; and I can appreciate the things you can build with it when doing it correctly. The depth of hole you can quickly end up in though is not to be underestimated. That and nigh every JS developer I've run into who says they are proficient knows nothing about really debugging it, or hasn't read the core library docs and really means they can use one framework or another. ...Bar like 3. Who you never want to bother, because they are usually handling issues way more important/wide-ranging that warrant their attention than hand-holding you through learning how it actually works.
- pwdisswordfish9 4y ago
  If you "don't have an issue" with JavaScript but you think the tools you're using are bad because of the "depth of hole you can quickly end up in though is not to be underestimated", then perhaps you should reconsider your decision to continue using them when you're writing JS and why you ever thought they were necessary. None of those things (package-lock.json, node_modules, or p?npm|yarn) actually come from ECMA-262...

ElectricalUnion 4y ago

> I've been bitten by (...) pnpm bs too many times. I'm surprised, the only node package manager that has any semblance of sanity is pnpm. No flattening BS. Not randomly adding extraneous undeclared dependencies on the dependency tree. Not allowing random dependencies to depend on extraneous undeclared dependencies on the dependency tree. Of course, then you find out that in the real life people actually use other package managers, and depend on non-deterministic, package flattening behavior and extraneous undeclared dependencies requiring extraneous undeclared dependencies...