Hacker News Reader

Comment by eric-p7 | Hacker News Reader

"has no dependencies, and uses only standard features of JavaScript so it works in any JS environment."

Then I see a Node style import and npm. When did Node/NPM stop being dependencies and become standardized by JavaScript? Where's my raw es6 module?

View on HN

FWIW the import syntax is now part of standard JS, according to the ECMAScript 2026 specification:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

And node seems to be used only as a dev dependency, to test, benchmark and build/package the project. If you'd be inclined you can use the project's code as-is elsewhere, i.e. in the browser.

Bare module specifiers aren't just for Node! Deno and browsers support import maps e.g.

The library doesn't use any APIs beyond those in the JS standard, so I'm pretty confident it will work everywhere, but happy to publish in more places and run more tests. Any in particular that you'd like to see?

Mostly unrelated, but does anyone know how are you supposed to make path-less module specifiers work for Node if you are not using npm but rather system-installed JS packages (Debian etc. install node-* packages into /usr/share/nodejs/)? With `require` it just works, but with `import` it errors and suggests passing the absolute path (even though it clearly knows what path ...).

For some reason everybody in the JS world takes "download and execute random software from the Internet" as the only way to do things.

Try import maps, something like:

    {
      "imports": {
        "express": "/usr/share/nodejs/express/index.js",
        "another-module": "/usr/share/nodejs/another-module/index.js"
      }
    }

Then run node like: `node --import-map=./import-map.json app.js`

The Debian approach of having global versions of libraries seems like it's solving a different problem than the ones I have. I want each application to track and version its own dependencies, so that upgrading a dependency for one doesn't break another, and so that I can go back to an old project and be reasonably confident it'll still work. That ultimately led me to nix.

I have a simpler solution to the latter problem: if upgrading a dependency package breaks anything (barring multi-year deprecation, limited-time experimental previews, etc.), I blacklist it and never install that package ever again. After all, they are clearly lacking on either their testing infrastructure or their development guidelines.

It's amazing how much the quality of installed software improves when you do this. Something our industry desperately needs.

Reply on news.ycombinator.com