4 ms·

When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages,

When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript". Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project itself: https://www.npmjs.com/package/esbuild?activeTab=dependencies https://www.npmjs.com/package/esbuild?activeTab=dependencies https://github.com/evanw/esbuild/blob/755da31752d759f1ea70b8d4f7f677b3557dab3e/go.mod https://github.com/evanw/esbuild/blob/755da31752d759f1ea70b8... Other "next generation" projects are trading one problematic ecosystem for another. When you study dependency chains of e.g. biomejs and swc, it looks pretty good: https://www.npmjs.com/package/@biomejs/biome/v/latest?activeTab=dependencies https://www.npmjs.com/package/@biomejs/biome/v/latest?active... https://www.npmjs.com/package/@swc/types?activeTab=dependencies https://www.npmjs.com/package/@swc/types?activeTab=dependenc... Replacing the tire fire of eslint (and its hundreds to low thousands of dependencies) with zero of them! Very encouraging, until you find the Rust source: https://github.com/biomejs/biome/blob/a0039fd5457d0df18242feed5d21ff868ceb0693/Cargo.toml https://github.com/biomejs/biome/blob/a0039fd5457d0df18242fe... https://github.com/swc-project/swc/blob/6c54969d69551f516032c22dbd9144e6ae5556b0/Cargo.toml https://github.com/swc-project/swc/blob/6c54969d69551f516032... I think as these projects gain more momentum, we will see similar things cropping up in the cargo ecosystem. Does anyone know of other major projects written in as strict a style as esbuild?

cookiengineer 1y ago
Part of the reason of my switch to using Go as my primary language is that there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. These kind of projects usually are pretty great because they aim to work with CGO_ENABLED=0 so the libs are very portable and work with different syscall backends. Additionally I really like to go mod vendor my snapshot of dependencies which is great for short term fixes, but it won't fix the cause in the long run. However, the go ecosystem is just as vulnerable here because of lack of signing off package updates. As long as there's no verification possible end-to-end when it comes to "who signed this package" then there's no way this will get better. Additionally most supply chaib attacks focussed on the CI/CD infrastructure in the past, because they are just as broken with just as many problems. There needs to be a better CI/CD workflow where signing keys don't have to be available on the runners themselves, otherwise this will just shift the attack surface to a different location. In my opinion the package managers are somewhat to blame here, too. They should encourage and mandate gpg signatures, and especially in git commits when they rely on git tags for distribution.
- juliend2 1y ago
  > there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being more low-level, where such tools are less ubiquitous?
  - christophilus 1y ago
    "A little duplication is better than a little dependency," -- Rob Pike I think the culture was set from the top. Also, the fairly comprehensive standard library helps a lot. C# was in a similar boat back when I used it.
  - johnisgood 1y ago
    C encourages such culture, too, FWIW.
    - deleted 1y ago
      [deleted]
  - Ajedi32 1y ago
    > I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. I think it's because the final deliverable of Go projects is usually a single self-contained binary executable with no dependencies, whereas with Node the final deliverable is usually an NPM package which pulls its dependencies automatically.
    - yunohn 1y ago
      > usually an NPM package which pulls its dependencies automatically Built applications do not pull dependencies at runtime, just like with golang. If you want to use a library/source, you pull in all the deps, again just like golang.
zelphirkalt 1y ago
The answer is to not draw in dependencies for things you are easily able to write yourself. That would probably reduce dependencies by 2/3 or so in many projects. Especially, left-pad things. If you write properly self contained small parts and a few tests, you probably don't have to touch them much, and the maintenance burden is not that high. Compare that with having to check every little dependency like left pad and all its code and its dependencies. If a dependency is not strictly necessary, then don't do it.
- user34283 1y ago
  That's not an answer at all. Jest alone adds 300 packages. Why don't you share with us what your project does and how many packages are present?
  - zelphirkalt 1y ago
    My current project? Not sure what that has to do with the discussion, but my current project uses only a tiny bit of JS and has a fallback for users who don't run JS. It is a few pages taking a file to upload and the all the actual sauce is in the backend, and it is rendering templates. So I simply avoid the whole problem altogether in my current project. But aside from the JS stuff, the backend is in Python and I avoid adding dependencies from PyPI wherever possible. For example I had the choice of going with Pydantic and dataclasses and whatnot, but I resisted that, and came up with a quite minimalistic way to type check JSON documents, that is contained in one short module and easily extensible. Does it go to the same length as pydantic? No, it doesn't. If it did, I would be a genious. But it is quite sufficient for type safety in my project. Keeping things simple is possible, if we set our minds to it. Sometimes one cannot avoid a big dependency, sure, but in many cases we actually can! We just need to beat that beast of habit of quickly adding a familiar dependency without thinking about the cost.
    - user34283 1y ago
      So you're not using the npm ecosystem at all. Surely you see how that might be relevant to the discussion where you appeared to give advice on how to solve the npm dependency graph problem. That you're not using npm or other node package managers at all is the key information here. Not that it's invalid, but it's a very different setup.
benmccann 1y ago
Yes, eslint is particularly frustrating: https://npmgraph.js.org/?q=eslint https://npmgraph.js.org/?q=eslint There are plenty of people in the community who would help reduce the number of dependencies, but it really requires the maintainers to make it a priority. Otherwise the only way to address it is to switch to another solution like oxlint.
- dmix 1y ago
  I tried upgrading ESLint recently and it took me forever to fix all the dependency issues. I wish I never used ESLint prettier as now my codebase styling is locked into an ESLint config :/
  - azemetre 1y ago
    Have you looked into biome? We recently switched at work. It’s fine and fast. If you overly rely on 3rd party plugins it might be hard but it covered our use case fine for a network based react app. Way less dependencies too.
    - dmix 1y ago
      Even minor styling rule changes would result in a huge PR across our frontend so I tend to avoid any change in tooling. But using old tools is not the end of the world. I only upgrade ESLint because I had to upgrade something else.
      - adhamsalama 1y ago
        Would omitting this commit from git blame solve the issue?
        dmix 1y ago
        Oh that's a great idea. I forgot about git --ignore-revs
  - WorldMaker 1y ago
a99c43f2d565504 1y ago
> Does anyone know of other major projects written in as strict a style as esbuild? As in any random major project with focus on not having dependencies? SQLite comes to mind.
philipwhiuk 1y ago
The downside is now I need to know Golang to audit my JavaScript project. And it runs a post-install: node install.js So I do really have to trust it or read all the code.
duped 1y ago
> Very encouraging, until you find the Rust source Those are the workspace dependencies, not the dependencies of the specific crates you may use within the project. You have to actually look closer to find that out, most of `swc-` crates have shallow dependency trees.

cookiengineer 1y ago

Part of the reason of my switch to using Go as my primary language is that there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. These kind of projects usually are pretty great because they aim to work with CGO_ENABLED=0 so the libs are very portable and work with different syscall backends. Additionally I really like to go mod vendor my snapshot of dependencies which is great for short term fixes, but it won't fix the cause in the long run. However, the go ecosystem is just as vulnerable here because of lack of signing off package updates. As long as there's no verification possible end-to-end when it comes to "who signed this package" then there's no way this will get better. Additionally most supply chaib attacks focussed on the CI/CD infrastructure in the past, because they are just as broken with just as many problems. There needs to be a better CI/CD workflow where signing keys don't have to be available on the runners themselves, otherwise this will just shift the attack surface to a different location. In my opinion the package managers are somewhat to blame here, too. They should encourage and mandate gpg signatures, and especially in git commits when they rely on git tags for distribution.

juliend2 1y ago
> there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being more low-level, where such tools are less ubiquitous?
- christophilus 1y ago
  "A little duplication is better than a little dependency," -- Rob Pike I think the culture was set from the top. Also, the fairly comprehensive standard library helps a lot. C# was in a similar boat back when I used it.
- johnisgood 1y ago
  C encourages such culture, too, FWIW.
  - deleted 1y ago
    [deleted]
- Ajedi32 1y ago
  > I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. I think it's because the final deliverable of Go projects is usually a single self-contained binary executable with no dependencies, whereas with Node the final deliverable is usually an NPM package which pulls its dependencies automatically.
  - yunohn 1y ago
    > usually an NPM package which pulls its dependencies automatically Built applications do not pull dependencies at runtime, just like with golang. If you want to use a library/source, you pull in all the deps, again just like golang.

zelphirkalt 1y ago

The answer is to not draw in dependencies for things you are easily able to write yourself. That would probably reduce dependencies by 2/3 or so in many projects. Especially, left-pad things. If you write properly self contained small parts and a few tests, you probably don't have to touch them much, and the maintenance burden is not that high. Compare that with having to check every little dependency like left pad and all its code and its dependencies. If a dependency is not strictly necessary, then don't do it.

user34283 1y ago
That's not an answer at all. Jest alone adds 300 packages. Why don't you share with us what your project does and how many packages are present?
- zelphirkalt 1y ago
  My current project? Not sure what that has to do with the discussion, but my current project uses only a tiny bit of JS and has a fallback for users who don't run JS. It is a few pages taking a file to upload and the all the actual sauce is in the backend, and it is rendering templates. So I simply avoid the whole problem altogether in my current project. But aside from the JS stuff, the backend is in Python and I avoid adding dependencies from PyPI wherever possible. For example I had the choice of going with Pydantic and dataclasses and whatnot, but I resisted that, and came up with a quite minimalistic way to type check JSON documents, that is contained in one short module and easily extensible. Does it go to the same length as pydantic? No, it doesn't. If it did, I would be a genious. But it is quite sufficient for type safety in my project. Keeping things simple is possible, if we set our minds to it. Sometimes one cannot avoid a big dependency, sure, but in many cases we actually can! We just need to beat that beast of habit of quickly adding a familiar dependency without thinking about the cost.
  - user34283 1y ago
    So you're not using the npm ecosystem at all. Surely you see how that might be relevant to the discussion where you appeared to give advice on how to solve the npm dependency graph problem. That you're not using npm or other node package managers at all is the key information here. Not that it's invalid, but it's a very different setup.

benmccann 1y ago

Yes, eslint is particularly frustrating: https://npmgraph.js.org/?q=eslint https://npmgraph.js.org/?q=eslint There are plenty of people in the community who would help reduce the number of dependencies, but it really requires the maintainers to make it a priority. Otherwise the only way to address it is to switch to another solution like oxlint.

dmix 1y ago
I tried upgrading ESLint recently and it took me forever to fix all the dependency issues. I wish I never used ESLint prettier as now my codebase styling is locked into an ESLint config :/
- azemetre 1y ago
  Have you looked into biome? We recently switched at work. It’s fine and fast. If you overly rely on 3rd party plugins it might be hard but it covered our use case fine for a network based react app. Way less dependencies too.
  - dmix 1y ago
    Even minor styling rule changes would result in a huge PR across our frontend so I tend to avoid any change in tooling. But using old tools is not the end of the world. I only upgrade ESLint because I had to upgrade something else.
    - adhamsalama 1y ago
      Would omitting this commit from git blame solve the issue?
      - dmix 1y ago
        Oh that's a great idea. I forgot about git --ignore-revs
- WorldMaker 1y ago

a99c43f2d565504 1y ago

> Does anyone know of other major projects written in as strict a style as esbuild? As in any random major project with focus on not having dependencies? SQLite comes to mind.

philipwhiuk 1y ago

The downside is now I need to know Golang to audit my JavaScript project. And it runs a post-install: node install.js So I do really have to trust it or read all the code.

duped 1y ago

> Very encouraging, until you find the Rust source Those are the workspace dependencies, not the dependencies of the specific crates you may use within the project. You have to actually look closer to find that out, most of `swc-` crates have shallow dependency trees.