4 ms·

you don’t need to use npm to add packages to a JS project

by sabbaticaldev 2y ago

davidmurdoch 2y ago
you don't need to use a mouse to use a computer. But you probably do.
- rollcat 2y ago
  Rolling with your metaphor, trackpoints, trackpads, trackballs, digitisers, or touchscreens are strongly preferred by many, as mice have usability tradeoffs & problems by design. Nobody here is arguing against code reuse (pointing devices).
  - davidmurdoch 2y ago
    Yeah, so they could have just answered my original question.
    - deleted 2y ago
      [deleted]
    - meiraleal 2y ago
      > What languages do you use that don't have a package manager? > Yeah, so they could have just answered my original question. That's not a real question, just you trying to be a know-it-all and failing miserably. conflating dependency management with npm is your mistake, especially now with ESM. You can just do import React from "https://esm.sh/react" No NPM needed
      - davidmurdoch 2y ago
        NPM is literally a package manager. No conflation is needed. No, I'm not. You just seem to think people are trying to be smart asses when they aren't. Don't try to quell curiosity with your cynicism. HN is a place for curiosity, let it be that way. In the esm.sh case, esm.sh is a CDN that is a proxy to NPM (and a build tool). The original commenter answered my questions. They use JS and TS with bazel. Which likely acts as a package manager for them, fetching packages from the npm registry for them - or the infra it uses does. EDIT, since meiraleal edited their comment while I was replying, here is their original comment: > conflating dependency management with npm is your mistake, especially now with ESM. You can just do > > import React from "https://esm.sh/react https://esm.sh/react" No NPM needed > > What languages do you use that don't have a package manager? > > Yeah, so they could have just answered my original question. > > That's not a real question just you trying to be a smart ass, wrongly, and insisting on it.
        meiraleal 2y ago
        > In the esm.sh case, esm.sh is a CDN that is a proxy to NPM (and a build tool). No, esm.sh in this case is just an external source for a JS file that happens to mirror NPM because that's the JS files people want to download. It could be github.com, both, multiple sources, using sourcemaps or just local. There is no need for a central package manager to manage dependencies nor a build step in modern JS with ESM and that's way better than installing thousands of npm packages in your local machine for a hello world project.
        davidmurdoch 2y ago
        > There is no need for a central package manager to manage dependencies nor a build step in modern JS with ESM and that's way better than installing thousands of npm packages in your local machine for a hello world project. > for a hello world project. I was coming at this from the perspective of real-world projects, sorry. The repo I work on most has over 4000 npm dependencies (including dev dependencies). There are even more in other repos from other teams that it depends on. If we had spread these out across a handful of sources (github, esm.sh, someone's random host, etc) I don't think an app of our size would ever see a day without some downtime*. In real world applications spreading dependencies across domains results in multiple points of failure instead of one (npm registry), you also have a much harder time with security (especially around automated security tools and auditing), dependency versioning becomes a bit trickier, managing updates are harder, ESM packages are far from ubiquitous, etc. I do understand the sentiment; it'd be nice to import from wherever and have the same guarantees that a centralized package manager provides, but that's not how things are right now. Maybe if you don't work in a large legacy app, or your systems don't need the security tools that have been built up around package managers, or you can afford increased load times from unbundled/unoptimized dependencies, the ESM dream works. But most significant apps can't go the "Vanilla JS" route. Sadly, "Vanilla" JS isn't as great as it can be, so leaning on tools to get the job done is great, and a centralized registry (with well-managed mirrors!) is a really great tool.

you don’t need to use npm to add packages to a JS project

davidmurdoch 2y ago

you don't need to use a mouse to use a computer. But you probably do.

rollcat 2y ago
Rolling with your metaphor, trackpoints, trackpads, trackballs, digitisers, or touchscreens are strongly preferred by many, as mice have usability tradeoffs & problems by design. Nobody here is arguing against code reuse (pointing devices).
- davidmurdoch 2y ago
  Yeah, so they could have just answered my original question.
  - deleted 2y ago
    [deleted]
  - meiraleal 2y ago
    > What languages do you use that don't have a package manager? > Yeah, so they could have just answered my original question. That's not a real question, just you trying to be a know-it-all and failing miserably. conflating dependency management with npm is your mistake, especially now with ESM. You can just do import React from "https://esm.sh/react" No NPM needed
    - davidmurdoch 2y ago
      NPM is literally a package manager. No conflation is needed. No, I'm not. You just seem to think people are trying to be smart asses when they aren't. Don't try to quell curiosity with your cynicism. HN is a place for curiosity, let it be that way. In the esm.sh case, esm.sh is a CDN that is a proxy to NPM (and a build tool). The original commenter answered my questions. They use JS and TS with bazel. Which likely acts as a package manager for them, fetching packages from the npm registry for them - or the infra it uses does. EDIT, since meiraleal edited their comment while I was replying, here is their original comment: > conflating dependency management with npm is your mistake, especially now with ESM. You can just do > > import React from "https://esm.sh/react https://esm.sh/react" No NPM needed > > What languages do you use that don't have a package manager? > > Yeah, so they could have just answered my original question. > > That's not a real question just you trying to be a smart ass, wrongly, and insisting on it.
      - meiraleal 2y ago
        > In the esm.sh case, esm.sh is a CDN that is a proxy to NPM (and a build tool). No, esm.sh in this case is just an external source for a JS file that happens to mirror NPM because that's the JS files people want to download. It could be github.com, both, multiple sources, using sourcemaps or just local. There is no need for a central package manager to manage dependencies nor a build step in modern JS with ESM and that's way better than installing thousands of npm packages in your local machine for a hello world project.
        davidmurdoch 2y ago
        > There is no need for a central package manager to manage dependencies nor a build step in modern JS with ESM and that's way better than installing thousands of npm packages in your local machine for a hello world project. > for a hello world project. I was coming at this from the perspective of real-world projects, sorry. The repo I work on most has over 4000 npm dependencies (including dev dependencies). There are even more in other repos from other teams that it depends on. If we had spread these out across a handful of sources (github, esm.sh, someone's random host, etc) I don't think an app of our size would ever see a day without some downtime*. In real world applications spreading dependencies across domains results in multiple points of failure instead of one (npm registry), you also have a much harder time with security (especially around automated security tools and auditing), dependency versioning becomes a bit trickier, managing updates are harder, ESM packages are far from ubiquitous, etc. I do understand the sentiment; it'd be nice to import from wherever and have the same guarantees that a centralized package manager provides, but that's not how things are right now. Maybe if you don't work in a large legacy app, or your systems don't need the security tools that have been built up around package managers, or you can afford increased load times from unbundled/unoptimized dependencies, the ESM dream works. But most significant apps can't go the "Vanilla JS" route. Sadly, "Vanilla" JS isn't as great as it can be, so leaning on tools to get the job done is great, and a centralized registry (with well-managed mirrors!) is a really great tool.