3 ms·

Unpopular opinion: code should have no dependencies. Thus, tools that ease the proliferation of dependencies encourage bad practices and must be avoided. If y

Unpopular opinion: code should have no dependencies. Thus, tools that ease the proliferation of dependencies encourage bad practices and must be avoided. If you want to use somebody's else code, copy it verbatim into your project. Avoid unstable third-party code that needs to be updated every year (or worse, every week).

eschneider 3y ago
Alas, sometimes that unstable third-party code is from some guy two desks down, and you need to use it. And it's unstable because it's not-quite-done yet. Dependencies are life. Sure, eliminate the ones you don't need, but on most larger(ish) projects, you're going to have dependencies, be them internal or external.
gadflyinyoureye 3y ago
I kind of agree with you. This is why I’m trying to move my team to Go for new development rather than TypeScript. I end up having to spend about one day per month fixing dependencies. Our versions are pinned but upstream someone just said, “use latest”. Then everything breaks and I have to upgrade our project from TypeScript 3 to 4 or 5. Then I have to figure out interdependencies. It’s a mess.
logophobia 3y ago
If your dependency has a security update, how are you going to get that if you copy-paste the code? The thing these dependency managers do well is that they notify you about these types of issues. .. That said, people need to be very careful about what they add as dependency. Having 1000+ transitive dependencies is just asking for security issues.
- magicalhippo 3y ago
  We effectively do the copy-paste. Dependencies are manually committed as a subdirectory to a "deps" directory, and the build scripts updated to search for it in that subdirectory. To update, we simply download the new version we want, replace the code in the subdirectory, do a build, make some tweaks if needed to build scripts and code, and run tests. Once it builds and tests are fine, we commit both the updated dependency and the other changes in one go. To get notified we use email (ie subscribe to updates) or just manually keep track. A nice side-effect of this is that it's trivial to study the changes between the old and the new version before committing. While subtle subterfuge would be hard to spot, blatant stuff like including a bitcoin miner or whatever is trivial to catch.
bob1029 3y ago
I definitely think you should minimize 3rd party dependencies. That is where things turn nasty fast. You want 1 chef in the kitchen wherever possible. This "open source" movement has sapped so much life force from many developers by forcing them to chase ideological rabbits around all day. I think it's intentional at this point too. I'm enjoying the magic of letting my framework/language vendor manage much of this circus for me. I am perfectly content being a filthy capitalist pig of a developer and paying money for my tools. Every time I can pay to outsource complexity, I am going to do it. If you are actually focused on problem solving, working with certain vendors that include most batteries can make for a significantly more productive and happy dev experience. Forcing yourself into dep management hell just so you can brag on twitter about avoiding that one evil vendor is accomplishing what, exactly? If you spend more than an hour a week worrying about dependencies, and you are trying to ship business functionality, why? Why suffer like this? Presumably the business to be implemented is already shitty enough. Why do we want to make it 10x harder with broken technology designs?
chriswarbo 3y ago
> If you want to use somebody's else code, copy it verbatim into your project. Copy/paste is a code smell ;) A nice middle ground is referencing the code you want via its hash; rather than some ambiguous, made up identifier. That way: - We retain the structure of separation, rather accumulating a big ball of mud. - There's nothing ambiguous that needs "resolving": a hash corresponds to precisely one (known) file; assuming the algo's not been broken ;) - Anyone using our project, anywhere in the world, at any time in the future, will get the exact same code. - References to the same hash can be shared across projects directly (no need for e.g. deduplicating filesystems) - We can reference multiple different copies/versions without conflict, since they'll have different hashes. - Referenced files can be cached for as long as we like (since they won't change, there's no invalidation; although we may want to "garbage collect" to save space) - No need for central "locations" (such as HTTP URLs): we can grab files from mirrors, P2P, other people's caches, etc. and it makes no difference to the file's hash. - No need to trust third-parties, e.g. using HTTPS, PGP, etc. since we can verify whether the file we receive has the hash we want. One way to do this is git submodules, although they rely on specific locations so we might want something like a magnet link for robustness and longevity. Another is IPFS, whose addresses are content hashes. Yet another is a tool like Nix, which has the advantage that we can calculate the contents of files; e.g. specifying our desired hashes in one place, and having them propagated/spliced/etc. as needed through the project (making it easier to update/replace in the future). We can also specify patches and arbitrary other pre-processing, to ensure we're getting precisely, and only, the code we want. Note that these aren't mutually-exclusive: Nix and Git work very well together, for example.
msla 3y ago
This is not always possible from a legal perspective.

eschneider 3y ago

Alas, sometimes that unstable third-party code is from some guy two desks down, and you need to use it. And it's unstable because it's not-quite-done yet. Dependencies are life. Sure, eliminate the ones you don't need, but on most larger(ish) projects, you're going to have dependencies, be them internal or external.

gadflyinyoureye 3y ago

I kind of agree with you. This is why I’m trying to move my team to Go for new development rather than TypeScript. I end up having to spend about one day per month fixing dependencies. Our versions are pinned but upstream someone just said, “use latest”. Then everything breaks and I have to upgrade our project from TypeScript 3 to 4 or 5. Then I have to figure out interdependencies. It’s a mess.

logophobia 3y ago

If your dependency has a security update, how are you going to get that if you copy-paste the code? The thing these dependency managers do well is that they notify you about these types of issues. .. That said, people need to be very careful about what they add as dependency. Having 1000+ transitive dependencies is just asking for security issues.

magicalhippo 3y ago
We effectively do the copy-paste. Dependencies are manually committed as a subdirectory to a "deps" directory, and the build scripts updated to search for it in that subdirectory. To update, we simply download the new version we want, replace the code in the subdirectory, do a build, make some tweaks if needed to build scripts and code, and run tests. Once it builds and tests are fine, we commit both the updated dependency and the other changes in one go. To get notified we use email (ie subscribe to updates) or just manually keep track. A nice side-effect of this is that it's trivial to study the changes between the old and the new version before committing. While subtle subterfuge would be hard to spot, blatant stuff like including a bitcoin miner or whatever is trivial to catch.

bob1029 3y ago

I definitely think you should minimize 3rd party dependencies. That is where things turn nasty fast. You want 1 chef in the kitchen wherever possible. This "open source" movement has sapped so much life force from many developers by forcing them to chase ideological rabbits around all day. I think it's intentional at this point too. I'm enjoying the magic of letting my framework/language vendor manage much of this circus for me. I am perfectly content being a filthy capitalist pig of a developer and paying money for my tools. Every time I can pay to outsource complexity, I am going to do it. If you are actually focused on problem solving, working with certain vendors that include most batteries can make for a significantly more productive and happy dev experience. Forcing yourself into dep management hell just so you can brag on twitter about avoiding that one evil vendor is accomplishing what, exactly? If you spend more than an hour a week worrying about dependencies, and you are trying to ship business functionality, why? Why suffer like this? Presumably the business to be implemented is already shitty enough. Why do we want to make it 10x harder with broken technology designs?

chriswarbo 3y ago

> If you want to use somebody's else code, copy it verbatim into your project. Copy/paste is a code smell ;) A nice middle ground is referencing the code you want via its hash; rather than some ambiguous, made up identifier. That way: - We retain the structure of separation, rather accumulating a big ball of mud. - There's nothing ambiguous that needs "resolving": a hash corresponds to precisely one (known) file; assuming the algo's not been broken ;) - Anyone using our project, anywhere in the world, at any time in the future, will get the exact same code. - References to the same hash can be shared across projects directly (no need for e.g. deduplicating filesystems) - We can reference multiple different copies/versions without conflict, since they'll have different hashes. - Referenced files can be cached for as long as we like (since they won't change, there's no invalidation; although we may want to "garbage collect" to save space) - No need for central "locations" (such as HTTP URLs): we can grab files from mirrors, P2P, other people's caches, etc. and it makes no difference to the file's hash. - No need to trust third-parties, e.g. using HTTPS, PGP, etc. since we can verify whether the file we receive has the hash we want. One way to do this is git submodules, although they rely on specific locations so we might want something like a magnet link for robustness and longevity. Another is IPFS, whose addresses are content hashes. Yet another is a tool like Nix, which has the advantage that we can calculate the contents of files; e.g. specifying our desired hashes in one place, and having them propagated/spliced/etc. as needed through the project (making it easier to update/replace in the future). We can also specify patches and arbitrary other pre-processing, to ensure we're getting precisely, and only, the code we want. Note that these aren't mutually-exclusive: Nix and Git work very well together, for example.

msla 3y ago

This is not always possible from a legal perspective.