3 ms·

IMO the best practice is to leave dependencies unpinned, but use a lock file, and only update the lock file a few times a year. Upgrade enough that you don’t g

IMO the best practice is to leave dependencies unpinned, but use a lock file, and only update the lock file a few times a year. Upgrade enough that you don’t get stuck, but not often enough to expose yourself to supply chain attacks every time CI runs.

rvz 4mo ago
The industry standard for the best peace of mind is for ALL dependencies to be pinned, both the lockfile and the dependencies. Upgrades are done manually and all characters such as "^", "*", next to the version are removed for a fixed predictable version to avoid unexpected version bumps or package hijacked in-case if they are compromised.
- bruhFaaahNo 4mo ago
  > The industry standard for the best peace of mind I read about "industry standards" in software and never see them in the wild. Odd to assume your own direct experience is uniformly distributed belief.
  - mgrandl 4mo ago
    Then you haven’t looked at a lot of open source repos? A ton of them are using renovate/dependabot which are doing exactly that for you. And it is certainly good practice.
    - bruhFaaahNo 4mo ago
      [flagged]
      - raincole 4mo ago
        It's a really weird hill to die on.
        bruhFaaahNo 4mo ago
        [flagged]
- OptionOfT 4mo ago
  The dependency file is more important for a library and less for an application. For a library, the dependency file (Cargo.toml, package.json, ...) defines the lowest version and its constraints of the library's dependencies when using the library in your project. It allows for the engine to try to resolve versions of common dependencies. E.g., in Rust: You have awesome-lib, and depend on dep-1. Your version constraint is 1.0.4, which allows for >=1.0.4 all the way up to <2. I use another-lib, which also depends on dep-1, But requires 1.4.2. The engine will then resolve it to a minimum of 1.4.2. If another library comes in and requires 2.8.3, then that dependency will be duplicated, and hopefully the API surface in those libraries don't expose the underlying dependency directly, because then you get funny errors like "These things have the same name but are actually different".
OJFord 4mo ago
That just means that you have whatever % chance of catching an attack on the days you do upgrade, and then in the event you do, stay compromised for a large % of the year until your next bump though? Constantly upgrading offers more days with that % chance of catching one, but at least means you'll see the fix or release-pull sooner too.
littlecorner 4mo ago
Perhaps upgrade to one a few versions out of date but confirmed to be good?

rvz 4mo ago

The industry standard for the best peace of mind is for ALL dependencies to be pinned, both the lockfile and the dependencies. Upgrades are done manually and all characters such as "^", "*", next to the version are removed for a fixed predictable version to avoid unexpected version bumps or package hijacked in-case if they are compromised.

bruhFaaahNo 4mo ago
> The industry standard for the best peace of mind I read about "industry standards" in software and never see them in the wild. Odd to assume your own direct experience is uniformly distributed belief.
- mgrandl 4mo ago
  Then you haven’t looked at a lot of open source repos? A ton of them are using renovate/dependabot which are doing exactly that for you. And it is certainly good practice.
  - bruhFaaahNo 4mo ago
    [flagged]
    - raincole 4mo ago
      It's a really weird hill to die on.
      - bruhFaaahNo 4mo ago
        [flagged]
OptionOfT 4mo ago
The dependency file is more important for a library and less for an application. For a library, the dependency file (Cargo.toml, package.json, ...) defines the lowest version and its constraints of the library's dependencies when using the library in your project. It allows for the engine to try to resolve versions of common dependencies. E.g., in Rust: You have awesome-lib, and depend on dep-1. Your version constraint is 1.0.4, which allows for >=1.0.4 all the way up to <2. I use another-lib, which also depends on dep-1, But requires 1.4.2. The engine will then resolve it to a minimum of 1.4.2. If another library comes in and requires 2.8.3, then that dependency will be duplicated, and hopefully the API surface in those libraries don't expose the underlying dependency directly, because then you get funny errors like "These things have the same name but are actually different".

OJFord 4mo ago

That just means that you have whatever % chance of catching an attack on the days you do upgrade, and then in the event you do, stay compromised for a large % of the year until your next bump though? Constantly upgrading offers more days with that % chance of catching one, but at least means you'll see the fix or release-pull sooner too.

littlecorner 4mo ago

Perhaps upgrade to one a few versions out of date but confirmed to be good?