I would expect this to only be an issue for externals and not for preserveModules as here, all imports are rewritten. Otherwise, this is a complicated topic: rollup itself does not know about Node.js semantics, only @rollup/plugin-node-resolve does. So this would be a feature request for the node-resolve plugin.

@lukastaegert I'm currently working on a PR to take care of requiring file extensions as an opt-in, also needed as a pre-cursor for file URLs and query params. should be up shortly.

Otherwise, this is a complicated topic: rollup itself does not know about Node.js semantics, only @rollup/plugin-node-resolve does

That's the official line, but we know that rollup does have some basic knowledge of NodeJS semantics even without any plugins specified in order to append file suffixes:

$ cat module/package.json 
{"type": "module"}

$ cat module/thing1.js 
import "./thing2";

$ cat module/thing2.js 
console.log("thing2.js");

rollup appends the ".js" suffix to import "./thing2"; in order to produce the output:

$ rollup module/thing1.js --silent
console.log("thing2.js");

NodeJS' path.resolve is called here in rollup core:

Rollup core also needs to read and write modules from the filesystem without plugins - something that requires the builtin fs module: https://github.com/rollup/rollup/blob/master/src/utils/fs.ts

I now think that Rollup 3.x should revisit the decision to not fold node-resolve and commonjs functionality into rollup core in order to give a more seamless user experience as other popular bundlers do. Rollup already has to have knowledge of NodeJS - so it might as well completely support it without the hassle of coordinating and specifying compatible versions of rollup, node-resolve and commonjs plugins.

It has long been discussed if the support for extensionless imports was a mistake, but I do not want to open this again, especially since TypeScript worked hard to shape expectations by enforcing it. But everything else is basically missing, Index imports, and all features that depend on package.json knowledge etc. That may be what most users want, but the separation has enabled quite a few niche usages for Rollup that set it apart. Also it allows others to completely customise the experience. There are quite a few tools that build on Rollup these days that give users the tailored experience, especially looking at Vite here.

I see your point - there's a lot of legacy usage out there. But what if the node-resolve and commonjs plugins were to just ship with rollup 3.x core and could be used with an opt-in flag? That alone would make it easier to use in the vast majority of user scenarios - no versioning, and no need to load or import them. I'd argue the flag should be an opt-out style option in rollup 3.x, but that's less likely to gain consensus.

@lukastaegert

especially since TypeScript worked hard to shape expectations by enforcing it

curious, what do you mean by that?

I see your point - there's a lot of legacy usage out there. But what if the node-resolve and commonjs plugins were to just ship with rollup 3.x core and could be used with an opt-in flag? That alone would make it easier to use in the vast majority of user scenarios - no versioning, and no need to load or import them. I'd argue the flag should be an opt-out style option in rollup 3.x, but that's less likely to gain consensus.

@kzc not sure if node-resolve and commonjs should go into core. that said, I think you (or someone else) mentioned somewhere that node-resolve and commonjs should potentially be one single plugin, to that I think I would agree, because commonjs as far as I know is only being used by node.js and so is the node.js resolution algorithm (which currently only works for commonjs as well).

I hope that the node.js resolution flag for esm will never be activated by default and subsequently be removed, as it only causes problems and makes everything more complex.

@lukastaegert I think Typescript had other (technical) reasons to not enforce extensions. Deno opted in by requiring them as well. I can't find any references of why Typescript decided not to require extensions.

(the esm version of) rollup itself only runs in the browser and in node.js because it's being bundled, otherwise it would be not possible to run rollup "unbundled", as the file extensions are missing.

to achieve running node.js esm, one has to use explicit file extensions with Typescript files as well.

I'm not suggesting to change the rollup core architecture. Just proposing to ship the plugins most users need with rollup core - node-resolve, commonjs and possibly json - and provide an opt-in shorthand option to enable those plugins with default options. It would only require a very small change to the rollup CLI. If users wish to use their traditional rollup config files, or command line options - it would not break backwards compatibility.

I'm not suggesting to change the rollup core architecture.

yeah, I figured. with core I meant rollup itself, not the implementation.

one thing I also noticed:

// index.js
import { foo } from "./foo";

console.log(foo);

// foo.js
export const foo = 1;

with preserveModules: true becomes:

// index.js
import { foo } from './foo.js';  //  <--- extension included :P

console.log(foo);

// foo.js
const foo = 1;

export { foo };

if this is not a bug but intentional, I would argue this to be another reason for requiring file extensions. 😉

@kzc configuring rollup with commonjs and node-resolve can definitely be a PITA. I have tried so many times (for node.js server code and lambdas etc.), that I have usually always switched to webpack (if I wanted to have the dependencies included, which, unfortunately, are mostly still commonjs).

I also get @lukastaegert reasoning to not have those included in core. for one, rollup started out as an esm-only bundler, expecting esm-only as input. as it looks for commonjs, the clock started ticking for it to slowly fade out of existence. granted, it might take years.

speaking of which, there is more module proposals on the horizon. should those in turn be included as well? 🤔
css modules: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md
html modules: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/HTMLModules/designDoc.md
wasm modules ...