Drop support for Node.js < 12

[guybedford]

Feature Use Case

The interpretation of rollup.config.js files doesn't quite match the Node.js execution model leading to subtle bugs.

Feature Proposal

If we drop support for Node.js < 12, we can update the rollup configuration loader to use the Node.js native loader entirely, effectively as simple as a dynamic import(), ensuring all packages imported in the configuration file behave like normal Node.js ES module packages.

[shellscape]

I'm for it

[lukastaegert]

So am I, see also #4123 (review)

For me it is more a question of "when".

So this obviously needs a major release, the question is just what else to put in there. I actually wanted to do two things before the next major release (and wanted to do so for a year now):

• Switch to ES2015+ generated code (ideally via an option)
• Fix the hashing algorithm to look at actually generated chunks

But while I have finally started work on the first one and have a concept for the second one, obviously this was not completed in the last year. So maybe we should decouple them (unless I accidentally make a lot of progress in the near future). But I collected a long laundry list of things for the next major release, and we should at least tackle the low-hanging fruit here: https://github.com/rollup/rollup/projects/3

My suggestion would be to handle this like the 2.0 release:

• Create a release branch release-3.0.0 from master
• Create PRs for those topics against the release branch (and possibly release pre-release versions after each PR is merged)
• Once we are happy with the release branch, do a proper non-squash merge of the release branch to master and release :)

I would be really happy if we could do this in parallel and also rather soon. Also, If you have other ideas that are sufficiently easy to add (e.g. changed defaults), please add them to the project and possibly as issues or PRs.

[guybedford]

If we're talking wish-lists I would love it if RollupJS could converge on URLs as the primary internal specifier mechanism to match Node.js, Deno and web.

[lukastaegert]

That could mean we break a lot of plugins if ids are suddenly urls, especially custom ad-hoc plugins. That is my primary fear which could really break Rollup's neck for dubious benefits.
On the other hand if this is just about extending the internal loader to be able to load ids that are urls, there is no issue with that.
Just remember, for most of Rollup, ids are not file locations, they are just ids. This is a big difference between Rollup and Node. There is also no concept of "converting" ids, that is why they are called ids and not locations, and converting would not make sense when you cannot really make assumptions about ids anyway. You can use urls as ids today if you write a loader and resolver plugin.
That being said, For most people, ids are not generated by Rollup core anyway but by the node-resolve plugin.
We could add an opt-in flag that tells the resolver to resolve relative imports to Urls if you want. But this would be non-breaking and could be done at any time, also to gather experience. But to make this breaking, I really fear this could massively hurt Rollup.

[frank-dspeed]

could we maybe with this even switch the codebase to esm and drop .ts extension that would be a dream. that does not hurt typescript support at all but makes the project directly useable. and it could finaly share the same module for the browser and node

[dnalborczyk]

for what it's worth, the official rollup plugins are already supporting node.js v12+ only.

[dnalborczyk]

could we maybe with this even switch the codebase to esm and drop .ts extension that would be a dream. that does not hurt typescript support at all but makes the project directly useable. and it could finaly share the same module for the browser and node

@frank-dspeed how would this work by just dropping the ts extension?

[frank-dspeed]

@dnalborczyk typescript supports allowJs and checkJs flags we can then use the .js extension and get typechecking and code hints as if we would use typescript .ts.

in most time the type inference will work even out of the box.

so we get code hints and type checking via typescript without the need to compile the project we can even create .d.ts files while they are pritty useless if you use .js as extension + jsdoc anottated types.

we can then add 2 entry points browser.js node.js and share a single module between them.

It helps me a lot to be able to work with unminifyed code directly without compilation or obfusication i can then simply import a module inside a other and create a new composed object that Implements my Algos.

At present i am maintaining a own automated rollup build that only compiles rollup into a ESM only Project.

because on the long run i am already working on typescript-rollup

i want to implement a good Plugin system into typescript and found out that rollup is a great fit for that i only need to make the AST Compatible as rollup uses acron at present.

Then the next feature is to integrate typescript-rollup language features into the Language Server to support Code hints based on Rollup Plugins and the other meta data that we get.

This will then finally enable

Typescript

• Alternativ Plugin based Resolve Algos
• Alternativ Plugin based Transforms
• Alternativ Plugin based Language Features for ECMAScript / JS / TS .....
• Live Debugging Bundle Stuff.

[dnalborczyk]

I think at this point it might be even sensible to drop support for node.js v12 as well, depending on how long v3 development will take. EOL April 2022 https://nodejs.org/en/about/releases/

[mreinstein]

We should wait until April. Once it's no longer a supported LTS I think it's fine to drop support.

[frank-dspeed]

@mreinstein i would still vote for a current release with droped support maybe as beta because so there is more time for adoption

[lukastaegert]

This issue has been resolved via #4548 as part of rollup@3.0.0-3. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-3 or npm install rollup@beta. It will likely become part of a regular release later.

[lukastaegert]

This issue has been resolved via #4548 as part of rollup@3.0.0-4. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-4 or npm install rollup@beta. It will likely become part of a regular release later.

[rollup-bot]

This issue has been resolved via #4548 as part of rollup@3.0.0-5. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-5 or npm install rollup@beta. It will likely become part of a regular release later.

[rollup-bot]

This issue has been resolved via #4548 as part of rollup@3.0.0-6. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-6 or npm install rollup@beta. It will likely become part of a regular release later.

[rollup-bot]

This issue has been resolved via #4548 as part of rollup@3.0.0-7. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-7 or npm install rollup@beta. It will likely become part of a regular release later.

[rollup-bot]

This issue has been resolved via #4548 as part of rollup@3.0.0-8. Note that this is a pre-release, so to test it, you need to install Rollup via npm install rollup@3.0.0-8 or npm install rollup@beta. It will likely become part of a regular release later.

[rollup-bot]

This issue has been resolved via #4548 as part of rollup@3.0.0. You can test it via npm install rollup.