17 ms·

No, this is highly unique to JS/TS. I've worked in plenty other languages and it's bo where near as bad. Yes they all have some form of this, but it's an order

by zo1 3y ago

No, this is highly unique to JS/TS. I've worked in plenty other languages and it's bo where near as bad. Yes they all have some form of this, but it's an order of magnitude smaller. One big contributor is JS's proclivity to have lots of smaller libraries. This increases the chances of one of the included libraries having a breaking change. Pile ontop of that this insane notion of constant version pinning and "semantic versioning" and you have devs that willy nilly change public facing interfaces.

satvikpendem 3y ago
Not really. Python's is worse for example.
- zo1 3y ago
  Sorry, I have to call BS on this. I'm hugely familiar with Python and used it for over 10 years, pretty much always on "latest version" instead of pinning. And had issues with incompatible versions less than 5 times. JS? Pretty much every single project, if any apreciable chunk of code gets ignored for a few months its almost guaranteed that it has breaking changes somewhere.
  - satvikpendem 3y ago
    I've been using Python longer than you have and I've always had issues. JS is bad for sure, but it's not "highly unique" to JS as the parent states.
- gkbrk 3y ago
  In Python it's really common to install or depend on packages without specifying or locking versions. When you want to use a new feature that's missing in the version you have, you can upgrade, but in general people expect things to stay in future versions.
chatmasta 3y ago
I agree that many packages in the JS ecosystem don't respect semantic versioning, which is why I pin my dependencies to an exact version. For updates, I rely on automated bots submitting PRs that update a single package at a time and run my test suites. But even if they did respect semver, I'd still use exact versions, because I want full control over when I update my dependencies, and I don't want lockfile updates leaking into unrelated PRs just because a developer ran `yarn install`. Yes, you can use `yarn install --immutable` (and you should in CI/prod), but this will fail if the lockfile changes, which it would if the semver resolved to an updated version. I just want to `yarn install` without changing the lockfile. If you pin to an exact version, and use a lockfile, then you won't ever pull in any updates on `yarn install`, and installing your package in three years will result in downloading the exact same code as it does today. Just make sure you use nvm to pin Node, and corepack to pin your package manager, and you have a fully reproducible build chain as long as the dependencies are not unpublished from npm (which they can't be, after 72 hours of publishing). The only time it makes sense to use a semver range is in the `peerDependencies` of a published library. Even the `dependencies` of a library should use an exact range. Why? Because firstly, if I'm following best practices, I should be bundling my library before publishing it as a package. And secondly, if that bundle depends on another package, that's okay because npm dependency model allows having multiple copies/versions of the same package. But if it's something like Emotion depending on React, where I only want one copy of the library at runtime, then I should use a peer dependency, and here it does make sense to refer to it with a semver range.
- satvikpendem 3y ago
  Exactly, people don't use (or commit to git) lockfiles and then are surprised when dependencies update, which is literally the point of what a lockfile is supposed to prevent.

by zo1 3y ago

satvikpendem 3y ago

Not really. Python's is worse for example.

zo1 3y ago
Sorry, I have to call BS on this. I'm hugely familiar with Python and used it for over 10 years, pretty much always on "latest version" instead of pinning. And had issues with incompatible versions less than 5 times. JS? Pretty much every single project, if any apreciable chunk of code gets ignored for a few months its almost guaranteed that it has breaking changes somewhere.
- satvikpendem 3y ago
  I've been using Python longer than you have and I've always had issues. JS is bad for sure, but it's not "highly unique" to JS as the parent states.
gkbrk 3y ago
In Python it's really common to install or depend on packages without specifying or locking versions. When you want to use a new feature that's missing in the version you have, you can upgrade, but in general people expect things to stay in future versions.

chatmasta 3y ago

I agree that many packages in the JS ecosystem don't respect semantic versioning, which is why I pin my dependencies to an exact version. For updates, I rely on automated bots submitting PRs that update a single package at a time and run my test suites. But even if they did respect semver, I'd still use exact versions, because I want full control over when I update my dependencies, and I don't want lockfile updates leaking into unrelated PRs just because a developer ran `yarn install`. Yes, you can use `yarn install --immutable` (and you should in CI/prod), but this will fail if the lockfile changes, which it would if the semver resolved to an updated version. I just want to `yarn install` without changing the lockfile. If you pin to an exact version, and use a lockfile, then you won't ever pull in any updates on `yarn install`, and installing your package in three years will result in downloading the exact same code as it does today. Just make sure you use nvm to pin Node, and corepack to pin your package manager, and you have a fully reproducible build chain as long as the dependencies are not unpublished from npm (which they can't be, after 72 hours of publishing). The only time it makes sense to use a semver range is in the `peerDependencies` of a published library. Even the `dependencies` of a library should use an exact range. Why? Because firstly, if I'm following best practices, I should be bundling my library before publishing it as a package. And secondly, if that bundle depends on another package, that's okay because npm dependency model allows having multiple copies/versions of the same package. But if it's something like Emotion depending on React, where I only want one copy of the library at runtime, then I should use a peer dependency, and here it does make sense to refer to it with a semver range.

satvikpendem 3y ago
Exactly, people don't use (or commit to git) lockfiles and then are surprised when dependencies update, which is literally the point of what a lockfile is supposed to prevent.