4 ms·

I feel like you may be blaming the tool for a social problem there. We have a simple rule: no changes to package* in a feature PR. Adding a dependency? Cool, up

I feel like you may be blaming the tool for a social problem there. We have a simple rule: no changes to package* in a feature PR. Adding a dependency? Cool, upgrade everything first, then add it fresh. (Be reasonable there- the idea is that the add should be clean, so if that can be done without doing a major upgrade, that is of course fine.)

bmitc 4y ago
It sounds like you're just working around the limitations of the tools. Edit: I think it's possible that I misunderstood, given the downvotes. I thought they meant that a dependency should be added in one PR, and then the feature needing that dependency in a separate PR. What I think they actually meant is that if adding a dependency requires upgrades of other dependencies, then upgrade the existing dependencies in one PR and then add the new dependency and feature in another single PR. That seems to make sense but not be necessarily a hard rule. As I said below though, I still think the tooling in this space is terrible. Even for dependencies, I don't want line and text changes in config and lock files. I want something that summarizes what dependencies were added or upgraded.
- alexchamberlain 4y ago
  Simply separating concerns so that each PR/commit focuses on 1 thing.
  - bmitc 4y ago
    But what is the one thing if you're just adding a dependency, where you're only adding it so that you can subsequently add a feature using it in a separate PR? The atomic action is adding the feature which requires the new dependency. Unless I misunderstood what you wrote. I still agree with the original comment in that diffing technology feels decades behind, and that a lot of what we do as software engineers are working around things the tooling should be doing better on.
    - LtWorf 4y ago
      You can review pr commit by commit… if the commits are poorly made just reject the changes and ask to make them properly.
    - sokoloff 4y ago
      It seems no different than adding a feature dark in one PR and turning it on in a second. “The atomic action is launching the new feature to users” seems like an equivalent argument (and one with which I disagree).
    - alexchamberlain 4y ago
      Sorry, I don't think I explained myself well. Generally when you see a lot of package* noise, it's because you've upgraded your dependencies, added one and made a feature change all at once. The main thing that needs to be separated is the upgrading part.
- sshine 4y ago
  Or a limitation of the human mind. If you jam too many unrelated changes into one diff, people stop paying attention, because now reviewing it requires many minutes and note-taking. Since hundreds of line changes can have little or no effect, but a single line change somewhere else can have drastic effects, it is essential to separate the unimportant from the important. Changes in dependencies is a not unimportant change, but they tend to get treated like noise because those changes are associated with automated tooling, like the package tool. Updating dependencies separately solves a social problem, not a technical one.
- cxr 4y ago
  > It sounds like you're just working around the limitations of the tools. It can be hard to recognize, esp. since it has so much cultural inertia and approval, but doing things like splitting things into packages, recording the links in package.json (whether by hand or by tool-assist), and then introducing something like `npm install` into the workflow as a way to lazily fetch parts of a application's codebase is nothing but one massive (and massively fragile) scheme to circumvent the version control system as an consequence of unacknowledged limitations of the relevant tool.
  - hinkley 4y ago
    Circumventing version control systems in part because of cognitive dissonance. If your dependencies are too big to check in, maybe you should look at that. With NodeJS in particular, the issue of binaries is sort of dodged by exploding the files out instead of reading them from archives like Java does. However version conflicts can easily result in many versions of the same files in your repository, so you're still in a bit of trouble where bloat is concerned. While you should start by putting your dependencies on a diet, a different organizational structure for files than what git uses, where copies and moves are tracked better would help a lot.

bmitc 4y ago

It sounds like you're just working around the limitations of the tools. Edit: I think it's possible that I misunderstood, given the downvotes. I thought they meant that a dependency should be added in one PR, and then the feature needing that dependency in a separate PR. What I think they actually meant is that if adding a dependency requires upgrades of other dependencies, then upgrade the existing dependencies in one PR and then add the new dependency and feature in another single PR. That seems to make sense but not be necessarily a hard rule. As I said below though, I still think the tooling in this space is terrible. Even for dependencies, I don't want line and text changes in config and lock files. I want something that summarizes what dependencies were added or upgraded.

alexchamberlain 4y ago
Simply separating concerns so that each PR/commit focuses on 1 thing.
- bmitc 4y ago
  But what is the one thing if you're just adding a dependency, where you're only adding it so that you can subsequently add a feature using it in a separate PR? The atomic action is adding the feature which requires the new dependency. Unless I misunderstood what you wrote. I still agree with the original comment in that diffing technology feels decades behind, and that a lot of what we do as software engineers are working around things the tooling should be doing better on.
  - LtWorf 4y ago
    You can review pr commit by commit… if the commits are poorly made just reject the changes and ask to make them properly.
  - sokoloff 4y ago
    It seems no different than adding a feature dark in one PR and turning it on in a second. “The atomic action is launching the new feature to users” seems like an equivalent argument (and one with which I disagree).
  - alexchamberlain 4y ago
    Sorry, I don't think I explained myself well. Generally when you see a lot of package* noise, it's because you've upgraded your dependencies, added one and made a feature change all at once. The main thing that needs to be separated is the upgrading part.
sshine 4y ago
Or a limitation of the human mind. If you jam too many unrelated changes into one diff, people stop paying attention, because now reviewing it requires many minutes and note-taking. Since hundreds of line changes can have little or no effect, but a single line change somewhere else can have drastic effects, it is essential to separate the unimportant from the important. Changes in dependencies is a not unimportant change, but they tend to get treated like noise because those changes are associated with automated tooling, like the package tool. Updating dependencies separately solves a social problem, not a technical one.
cxr 4y ago
> It sounds like you're just working around the limitations of the tools. It can be hard to recognize, esp. since it has so much cultural inertia and approval, but doing things like splitting things into packages, recording the links in package.json (whether by hand or by tool-assist), and then introducing something like `npm install` into the workflow as a way to lazily fetch parts of a application's codebase is nothing but one massive (and massively fragile) scheme to circumvent the version control system as an consequence of unacknowledged limitations of the relevant tool.
- hinkley 4y ago
  Circumventing version control systems in part because of cognitive dissonance. If your dependencies are too big to check in, maybe you should look at that. With NodeJS in particular, the issue of binaries is sort of dodged by exploding the files out instead of reading them from archives like Java does. However version conflicts can easily result in many versions of the same files in your repository, so you're still in a bit of trouble where bloat is concerned. While you should start by putting your dependencies on a diet, a different organizational structure for files than what git uses, where copies and moves are tracked better would help a lot.