News for hackers. Stuff that matters.
Re:Fetch API has landed into Node.js by kichimi on Tuesday February 01, 2022 @08:22AM (#30162006)
I do have a question that's only tangibly related to fetch, I was wondering what Nodes stance is on the seemingly increasing gap between the NodeJS and browser implementations of the JavaScript engine.

It's still very common to see Node modules that use require(), for example, but would otherwise work flawlessly in a browser where there is no require() support (without using shims and other libraries).

Re:Fetch API has landed into Node.js by jeswin on Tuesday February 01, 2022 @08:51AM (#30162325)
> I was wondering what Nodes stance is on the seemingly increasing gap between the NodeJS and browser implementations of the JavaScript engine. It's still very common to see Node modules that use require()...

"Seemingly increasing gap" - how did you come to that conclusion? If anything the gap has reduced since the availability of ES modules. I see more and more libraries preferring ES modules, but ultimately that's up to the library developers.

Re:Fetch API has landed into Node.js by inglor on Tuesday February 01, 2022 @08:25AM (#30162031)
I don't speak for the project a whole :)

Node has supported ESModules (`import`) for a while and you can use it (either by naming your files `.mjs` or setting `type: module` in your package.json.

There is a solid interop story between require/import and you can mix if you want.

`require` is going to be supported "forever" so code doesn't break and both module systems work.

As for the general question: Node is committed to supporting modern JavaScript and to not allow such a gap to be created. If you see a place Node doesn't do a great job at that please tell us!

Re:Fetch API has landed into Node.js by arcatek on Tuesday February 01, 2022 @08:37AM (#30162166)
However note that ESM in Node comes with drawbacks that prevent end-users from relying them in various situations. Those will be mostly solved once loaders become stable, but until then it's still advised to ship packages as both CJS and ESM.
Re:Fetch API has landed into Node.js by rattray on Tuesday February 01, 2022 @08:44AM (#30162251)
How do you do both?
Re:Fetch API has landed into Node.js by arcatek on Tuesday February 01, 2022 @10:47AM (#30164059)
Usually you setup a transpiler to target both. For example, my packages are bundled with rollup towards both cjs & esm:

https://github.com/arcanis/clipanion/blob/master/rollup.conf...

Re:Fetch API has landed into Node.js by rattray on Tuesday February 01, 2022 @03:26PM (#30168721)
Helpful, thank you!
Re:Fetch API has landed into Node.js by inglor on Tuesday February 01, 2022 @09:01AM (#30162475)
It's very easy to re-export ESM (import) as CJS (require) and vice-versa. The main issue is that ESM by default

For example to use `require` inside ESModules you would do:

```mjs import { createRequire } from 'module'; const require = createRequire(import.meta.url); require('./whatever-in-cjs'); ```

There is a reason this isn't "by default" though since ESM doesn't "silently" interop with CJS to not make writing universal code harder.