4 ms·

This is a natural and not really scary thing. All code is built on mountains of dependencies that by their nature will do more than what you are using them for

This is a natural and not really scary thing. All code is built on mountains of dependencies that by their nature will do more than what you are using them for. For example, part of cargo watch is to bring in a win32 API wrapper library (which is just autogenerated bindings for win32 calls). Of course that thing is going to be massive while watch is using only a sliver of it in the case it's built for windows. The standard library for pretty much any language will have millions of lines of code, that's not scary even though your apps likely only use a fraction of what's offered. And have you ever glanced at C++'s boost library? That thing is monstrously big yet most devs using it are going to really only grab a few of the extensions. The alternative is the npm hellscape where you have a package for "isOdd" and a package for "is even" that can break the entire ecosystem if the owner is disgruntled because everything depends on them. Having fewer larger dependencies maintained and relied on by multiple people is much more ideal and where rust mostly finds itself.

preommr 2y ago
> The alternative is the npm hellscape where you have a package for "isOdd" and a package for "is even" that can break the entire ecosystem if the owner is disgruntled because everything depends on them. This used to be true 5-10 years ago. The js ecosystem moves fast and much has been done to fix the dependency sprawl.
- dartos 2y ago
  I… don’t think that’s true. Just look at how many downloads some of those packages have today. Look at the dependency tree for a next or nuxt app. What the js world did is make their build systems somewhat sane, whatwith not needing babel in every project anymore.
  - throwitaway1123 2y ago
    > Look at the dependency tree for a next Looks ok to me: https://npmgraph.js.org/?q=next https://npmgraph.js.org/?q=next Ironically, most of the dependencies are actually Rust crates used by swc and turbopack [1][2]. Try running `cargo tree` on either of those crates, it's enlightening to say the least. And of course, Node has a built in file watcher, and even the most popular third party package for file watching (Chokidar) has a single dependency [3]. [1] https://github.com/vercel/next.js/blob/07a55e03a31b16da1d0855f0309e2d8cf32e6113/Cargo.toml https://github.com/vercel/next.js/blob/07a55e03a31b16da1d085... [2] https://github.com/swc-project/swc/blob/b94a0e1fd2b900b05c5f18d3d993a74ff9cc6e7d/Cargo.toml https://github.com/swc-project/swc/blob/b94a0e1fd2b900b05c5f... [3] https://npmgraph.js.org/?q=chokidar https://npmgraph.js.org/?q=chokidar
    - dartos 2y ago
      Not sure what npmgraph is doing exactly, but there are more dependencies than that. React is a dependency of every next application, but I don’t see it there. Maybe next, the singular package, has fewer dependencies than a project made with next.
      - throwitaway1123 2y ago
        React and react-dom are peer dependencies (npmgraph lists them but doesn't graph them visually). The actual full installation command is: `npm install next@latest react@latest react-dom@latest`[1]. Even if you include react and react-dom, the dependency graph still looks tolerable to me: https://npmgraph.js.org/?q=next%4014.2.13%2C+react%4018.3.1%2C+react-dom%4018.3.1 https://npmgraph.js.org/?q=next%4014.2.13%2C+react%4018.3.1%... [1] https://nextjs.org/docs/getting-started/installation#manual-installation https://nextjs.org/docs/getting-started/installation#manual-...
throwitaway1123 2y ago
> The alternative is the npm hellscape where you have a package for "isOdd" and a package for "is even" that can break the entire ecosystem if the owner is disgruntled because everything depends on them. The is-odd and is-even packages are in no way situated to break the ecosystem. They're helper functions that their author (Jon Schlinkert) used as dependencies in one of his other packages (micromatch) 10 years ago, and consequently show up as transitive dependencies in antiquated versions of micromatch. No one actually depends on this package indirectly in 2024 (not even the author himself), and very few packages ever depended on it directly. Micromatch is largely obsolete given the fact that Node has built in globbing support now [1][2]. We have to let some of these NPM memes go. [1] https://nodejs.org/docs/latest-v22.x/api/path.html#pathmatchesglobpath-pattern https://nodejs.org/docs/latest-v22.x/api/path.html#pathmatch... [2] https://nodejs.org/docs/latest-v22.x/api/fs.html#fspromisesglobpattern-options https://nodejs.org/docs/latest-v22.x/api/fs.html#fspromisesg...

preommr 2y ago

dartos 2y ago
I… don’t think that’s true. Just look at how many downloads some of those packages have today. Look at the dependency tree for a next or nuxt app. What the js world did is make their build systems somewhat sane, whatwith not needing babel in every project anymore.
- throwitaway1123 2y ago
  > Look at the dependency tree for a next Looks ok to me: https://npmgraph.js.org/?q=next https://npmgraph.js.org/?q=next Ironically, most of the dependencies are actually Rust crates used by swc and turbopack [1][2]. Try running `cargo tree` on either of those crates, it's enlightening to say the least. And of course, Node has a built in file watcher, and even the most popular third party package for file watching (Chokidar) has a single dependency [3]. [1] https://github.com/vercel/next.js/blob/07a55e03a31b16da1d0855f0309e2d8cf32e6113/Cargo.toml https://github.com/vercel/next.js/blob/07a55e03a31b16da1d085... [2] https://github.com/swc-project/swc/blob/b94a0e1fd2b900b05c5f18d3d993a74ff9cc6e7d/Cargo.toml https://github.com/swc-project/swc/blob/b94a0e1fd2b900b05c5f... [3] https://npmgraph.js.org/?q=chokidar https://npmgraph.js.org/?q=chokidar
  - dartos 2y ago
    Not sure what npmgraph is doing exactly, but there are more dependencies than that. React is a dependency of every next application, but I don’t see it there. Maybe next, the singular package, has fewer dependencies than a project made with next.
    - throwitaway1123 2y ago
      React and react-dom are peer dependencies (npmgraph lists them but doesn't graph them visually). The actual full installation command is: `npm install next@latest react@latest react-dom@latest`[1]. Even if you include react and react-dom, the dependency graph still looks tolerable to me: https://npmgraph.js.org/?q=next%4014.2.13%2C+react%4018.3.1%2C+react-dom%4018.3.1 https://npmgraph.js.org/?q=next%4014.2.13%2C+react%4018.3.1%... [1] https://nextjs.org/docs/getting-started/installation#manual-installation https://nextjs.org/docs/getting-started/installation#manual-...

throwitaway1123 2y ago

> The alternative is the npm hellscape where you have a package for "isOdd" and a package for "is even" that can break the entire ecosystem if the owner is disgruntled because everything depends on them. The is-odd and is-even packages are in no way situated to break the ecosystem. They're helper functions that their author (Jon Schlinkert) used as dependencies in one of his other packages (micromatch) 10 years ago, and consequently show up as transitive dependencies in antiquated versions of micromatch. No one actually depends on this package indirectly in 2024 (not even the author himself), and very few packages ever depended on it directly. Micromatch is largely obsolete given the fact that Node has built in globbing support now [1][2]. We have to let some of these NPM memes go. [1] https://nodejs.org/docs/latest-v22.x/api/path.html#pathmatchesglobpath-pattern https://nodejs.org/docs/latest-v22.x/api/path.html#pathmatch... [2] https://nodejs.org/docs/latest-v22.x/api/fs.html#fspromisesglobpattern-options https://nodejs.org/docs/latest-v22.x/api/fs.html#fspromisesg...