4 ms·

How does that solve the issue here of new broken versions of packages being published?

by detaro 5y ago

ses1984 5y ago
You shouldn't blindly pull updates into production, how do you know if a non-malicious update breaks your app if you don't do any basic testing first?
oblio 5y ago
That's another JS ecosystem widespread malpractice. Autobumping versions, or version ranges as they're called in Maven land. Dependencies should only use fixed versions and all updates should be manual. You should only use auto-upgradable versions during development, and the package manager should warn you that you're using them (or your dependencies are).
- codebje 5y ago
  If package A depends on package C at version 1.0 but package B depends on C at version 1.1, what version of C will be pulled in? Dependency management is not as simple as only upgrading one direct dependency at a time after careful review. The NPM ecosystem is particularly difficult to work with as it has deep and broad transitive dependency trees, many small packages, and a very high rate of change. You either freeze everything and hope you don't have an unpatched vulnerability somewhere or update everything and hope you don't introduce a vulnerability somewhere.
  - oblio 5y ago
    There are package exclusions, package forcing and of course, full dependency tree checks where you review what everything pulls in. The JS ecosystem will probably have to change but because it's so decentralized, that change will be orders of magnitude harder than, for example, PHPs transition from 3 (4, 5) to 7.
    - throw_m239339 5y ago
      > The JS ecosystem will probably have to change but because it's so decentralized, Is it? Everybody is pulling from Microsoft owned servers now, as Microsoft owns both Github and NPM.
      - oblio 5y ago
        You're right in the package storage sense. I don't think you're right in the builder/building practices sense.
  - throw_m239339 5y ago
    > Dependency management is not as simple as only upgrading one direct dependency at a time after careful review. Most package managers won't allow these stunts and conflicts have to be resolved UPSTREAM. NPM chose to go the "YOLO" way and will fetch every single version of a package that meets the dependency demands. Terrible design, but the purpose of that was growth for NPM, the company, not the best interest of the ecosystem.
- dvdcxn 5y ago
  I'm sorry but this is completely wrong. NPM has lock files which explicitly lockdown the version you have downloaded after your first install. These are commited to source control, so all subsequent installs will use the exact same version of dependencies, and nested dependencies too. You need to ask npm to upgrade or delete your lock file and node modules to run into this issue.

How does that solve the issue here of new broken versions of packages being published?

by detaro 5y ago

How does that solve the issue here of new broken versions of packages being published?

ses1984 5y ago

You shouldn't blindly pull updates into production, how do you know if a non-malicious update breaks your app if you don't do any basic testing first?

oblio 5y ago

That's another JS ecosystem widespread malpractice. Autobumping versions, or version ranges as they're called in Maven land. Dependencies should only use fixed versions and all updates should be manual. You should only use auto-upgradable versions during development, and the package manager should warn you that you're using them (or your dependencies are).

codebje 5y ago
If package A depends on package C at version 1.0 but package B depends on C at version 1.1, what version of C will be pulled in? Dependency management is not as simple as only upgrading one direct dependency at a time after careful review. The NPM ecosystem is particularly difficult to work with as it has deep and broad transitive dependency trees, many small packages, and a very high rate of change. You either freeze everything and hope you don't have an unpatched vulnerability somewhere or update everything and hope you don't introduce a vulnerability somewhere.
- oblio 5y ago
  There are package exclusions, package forcing and of course, full dependency tree checks where you review what everything pulls in. The JS ecosystem will probably have to change but because it's so decentralized, that change will be orders of magnitude harder than, for example, PHPs transition from 3 (4, 5) to 7.
  - throw_m239339 5y ago
    > The JS ecosystem will probably have to change but because it's so decentralized, Is it? Everybody is pulling from Microsoft owned servers now, as Microsoft owns both Github and NPM.
    - oblio 5y ago
      You're right in the package storage sense. I don't think you're right in the builder/building practices sense.
- throw_m239339 5y ago
  > Dependency management is not as simple as only upgrading one direct dependency at a time after careful review. Most package managers won't allow these stunts and conflicts have to be resolved UPSTREAM. NPM chose to go the "YOLO" way and will fetch every single version of a package that meets the dependency demands. Terrible design, but the purpose of that was growth for NPM, the company, not the best interest of the ecosystem.
dvdcxn 5y ago
I'm sorry but this is completely wrong. NPM has lock files which explicitly lockdown the version you have downloaded after your first install. These are commited to source control, so all subsequent installs will use the exact same version of dependencies, and nested dependencies too. You need to ask npm to upgrade or delete your lock file and node modules to run into this issue.