3 ms·

What languages do you use that don't have a package manager?

by davidmurdoch 2y ago

sabbaticaldev 2y ago
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.
mattlondon 2y ago
JavaScript and typescript.
- davidmurdoch 2y ago
  Interesting. Do you write software professionally?
  - mattlondon 2y ago
    Yes. Full time frontend using typescript and angular, but without node or npm. We use bazel.
    - davidmurdoch 2y ago
      Are you using something like esm.sh, or does bazel download external packages and bundle them for you? Or via some other means?
      - mattlondon 2y ago
        Bazel is a build tool, not a dependency management tool. There are no dynamic imports or downloads. You build from source. Dependencies are merged into our monorepo very sparingly - angular is "batteries included" so you don't need to import hundreds of thousands of extra dependencies and transient-dependencies to build a functional site like you need to do with other frameworks. Left-pad issues simply do not happen this way.
        davidmurdoch 2y ago
        The way many talk about it made me believe it is essentially an "everything" tool, and if it can't do something it's probably possible to extend it to do it. And from what I've read (I haven't used it myself) Bazel has some internal and external dependency management built in. And there are many JS related build rules for Bazel (https://bazel.build/docs/bazel-and-javascript https://bazel.build/docs/bazel-and-javascript), and at least one of these looks like it would enable npm. > Dependencies are merged into our monorepo very sparingly Oh that must be nice. The project I'm working on (a browser extension) currently has 4083 dependencies (including dev dependencies).

What languages do you use that don't have a package manager?

sabbaticaldev 2y ago

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.

mattlondon 2y ago

JavaScript and typescript.

davidmurdoch 2y ago
Interesting. Do you write software professionally?
- mattlondon 2y ago
  Yes. Full time frontend using typescript and angular, but without node or npm. We use bazel.
  - davidmurdoch 2y ago
    Are you using something like esm.sh, or does bazel download external packages and bundle them for you? Or via some other means?
    - mattlondon 2y ago
      Bazel is a build tool, not a dependency management tool. There are no dynamic imports or downloads. You build from source. Dependencies are merged into our monorepo very sparingly - angular is "batteries included" so you don't need to import hundreds of thousands of extra dependencies and transient-dependencies to build a functional site like you need to do with other frameworks. Left-pad issues simply do not happen this way.
      - davidmurdoch 2y ago
        The way many talk about it made me believe it is essentially an "everything" tool, and if it can't do something it's probably possible to extend it to do it. And from what I've read (I haven't used it myself) Bazel has some internal and external dependency management built in. And there are many JS related build rules for Bazel (https://bazel.build/docs/bazel-and-javascript https://bazel.build/docs/bazel-and-javascript), and at least one of these looks like it would enable npm. > Dependencies are merged into our monorepo very sparingly Oh that must be nice. The project I'm working on (a browser extension) currently has 4083 dependencies (including dev dependencies).