Open 0xdevalias opened 11 months ago
Skimming the rollup
CHANGELOG
from 2.35.1
(2020-12-14
) to 2.79.1
(2022-09-22
, the last version before 3.x
), there don't seem to be any obvious breaking changes:
3.0.0
(2022-10-11
) lists a number of breaking changes that will need to be investigated deeper:
There don't appear to be any obvious breaking changes between 3.0.0
(2022-10-11
) and 3.16.0
(2023-02-17
):
There don't appear to be any obvious breaking changes between 3.16.0
(2023-02-17
) and 3.29.4
(2023-09-28
, the last version before 4.x
):
4.0.0
(2023-10-05
) lists a number of breaking changes that will need to be investigated deeper:
There don't appear to be any obvious breaking changes between 4.0.0
(2023-10-05
) and 4.6.1
(2023-11-30
):
@rschristian Can you have a quick look at the breaking changes in the 3.0.0
and 4.0.0
releases of rollup
and advise whether you're happy for those with regards to microbundle
(eg. specifically 'flow on' things like minimum required node
version, etc).
If you're happy with those (or those up to a certain point), then I can look at what further changes will be required to bump the rollup
version + related plugins/etc here.
Eyeballing it, would say 3 is fine, 4 is probably not.
This might be a considerable amount of work -- depending on new defaults, might have to do a fair bit of tuning to keep module sizes down. Last I checked, 3 increased our outputs by a non-negligible amount.
output.sourcemapIgnoreList (required to implement https://github.com/developit/microbundle/issues/1066) support was added in 3.16.0 (2023-02-17):
Not sure this is the case ("required to implement"), should be doable with a dead-simple plugin, no need for upgrading.
Edit: Quick example:
function IgnoreListPlugin() {
return {
name: 'ignore-list-plugin',
generateBundle(_opts, bundle) {
const sourcemaps = Object.keys(bundle).filter((file) => /\.map$/.test(file));
for (const file of sourcemaps) {
const map = bundle[file];
map.x_google_ignoreList = [ /* something */ ];
bundle[file].source = JSON.stringify(map);
}
}
}
}
@rschristian Is there some way to make rollup use this type of custom plugin when bundling with microbundle?
@daun Only by editing Microbundle's Rollup config directly.
Eyeballing it, would say 3 is fine, 4 is probably not.
@rschristian Are you able to give some context on the 'why' of that? Is it the switch from XX to swc
in 4.x
that gives you doubts? Or something else?
This might be a considerable amount of work -- depending on new defaults, might have to do a fair bit of tuning to keep module sizes down. Last I checked, 3 increased our outputs by a non-negligible amount.
@rschristian Noted. I figure at the very least I can play around and add some info here that confirms that one way or the other.
My current thoughts on approach are to bump to latest 2.x
+ check that. Then try 3.x
and check that (potentially both 3.0
and then latest 3.x
), and then finally try 4.x
; or at least find the point along that journey where required plugins/etc aren't able to work any more, etc.
Do you have a set of 'canonical repos' you test with microbundle
for checking size changes/etc? I know preact
, but would there be any others worth looking at as well, or is that 'good enough'?
I also see the following in tools/
which seem to relate to do some file size things; maybe that's the more canonical comparisons:
Not sure this is the case ("required to implement"), should be doable with a dead-simple plugin, no need for upgrading.
@rschristian Mm, fair enough. I guess I was thinking of it from a 'use the support in the tool' rather than 'roll your own' approach, but yeah, hacking it in via a plugin would probably work as well.
Since my mind is in this space though, I figure I'll at least do some initial recon on how big the 'modernise rollup version' work seems like it will end up being.
Are you able to give some context on the 'why' of that?
I don't love bumping min Node to 18 so quickly.
Do you have a set of 'canonical repos' you test with microbundle for checking size changes/etc? I know preact, but would there be any others worth looking at as well, or is that 'good enough'?
Not really, I think our test suite here is usually a good way to check that. It could always be better of course, but it'll generally catch most issues.
I guess I was thinking of it from a 'use the support in the tool' rather than 'roll your own' approach
Long term, sure, but rolling our own will take a fraction of the time to land.
It's not exactly complicated functionality to stick an additional key into a sourcemap, after all.
Looking at the dependencies
in package.json
, the following seem to relate to rollup
plugins that may need version bumps alongside the main rollup
package:
"@rollup/plugin-alias": "^3.1.1"
v4.0.0
(2022-10-07
) seems to have breaking changes preparing for rollup
3.x
v5.0.0
(2023-04-04
) / v5.0.1
(2023-10-05
) seems to have breaking changes preparing for rollup
4.x
v5.1.0
(2023-11-25
) seems to be the latest"@rollup/plugin-babel": "^5.2.2"
v6.0.0
(2022-10-08
) preparing for rollup
3.x
v6.0.4
(2023-10-05
) preparing for rollup
4.x
, and seems to be the latest"@rollup/plugin-commonjs": "^17.0.0"
v23.0.0
(2022-10-09
) preparing for rollup
3.x
v25.0.5
(2023-10-05
) preparing for rollup
4.x
v25.0.7
(2023-10-15
) seems to be the latest"@rollup/plugin-json": "^4.1.0"
v5.0.0
(2022-10-10
) preparing for rollup
3.x
v6.0.1
(2023-10-05
) preparing for rollup
4.x
, and seems to be the latest"@rollup/plugin-node-resolve": "^11.0.1"
v15.0.0
(2022-10-10
) preparing for rollup
3.x
v15.2.2
(2023-10-05
) preparing for rollup
4.x
v15.2.3
(2023-10-08
) seems to be the latest"@surma/rollup-plugin-off-main-thread": "^2.2.2"
v2.2.3
(2021-11-02
) seems to be the latest"rollup-plugin-bundle-size": "^1.0.3"
v1.1.0
(2018-03-09
) seems to be the latest by the releases..1.0.3
"rollup-plugin-postcss": "^4.0.0"
4.0.2
(2021-11-22
) seems to be the latest"rollup-plugin-terser": "^7.0.2"
This package has been deprecated and is no longer maintained. Please use
@rollup/plugin-terser
v7.0.2
(2020-09-05
) was the last release before being deprecatedv0.1.0
(2022-10-27
) initial releasev0.4.4
(2023-10-05
) preparing for rollup
4.x
"rollup-plugin-typescript2": "^0.32.0"
v0.34.0
(2022-09-13
) requires rollup
2.60.0+
v0.36.0
(2023-09-28
) seems to be the latest"rollup-plugin-visualizer": "^5.6.0"
v5.8.3
(2022-10-16
) support for rollup
3.x
v5.9.3
(2023-11-25
) support for rollup
4.x
v5.10.0
(2023-12-04
) seems to be the latestWhile it's OOS of this issue, there may also be potential benefits in bumping dependencies such as:
"terser": "^5.7.0"
v5.25.0
(2023-12-05
) seems to be the latest"tslib": "^2.0.3"
v2.6.2
(2023-08-19
) seems to be the latest"autoprefixer": "^10.1.0"
v10.4.16
(21-09-2023
) seems to be the latest"builtin-modules": "^3.1.0"
v3.3.0
(2022-05-12
) seems to be the latestAlso:
console.warn
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
Why you should do it regularly:
https://github.com/browserslist/browserslist#browsers-data-updating
I don't love bumping min Node to 18 so quickly.
@rschristian nods, makes sense. Though 18 has already passed active support, and has about another 1yr 4mo left on security support; so while it's not required yet, it would make sense to move forward by the time security support ends IMO:
That said, at least a cursory skim seems to suggest that rollup
4.x
may not be any faster/etc yet anyway:
The parser from acorn to swc in Rollup v4. It seems that there is no performance improvement from Rollup v3 to v4.
The benchmarks are also improving slowly as we optimize some parts of the code and collect low-hanging fruit, though the biggest improvements are yet to come.
Not really, I think our test suite here is usually a good way to check that.
@rschristian Cool, sounds good.
Currently builds itself as:
⇒ npm run build
> microbundle@0.15.1 build
> npm run -s build:babel && npm run -s build:self
Build "microbundle" to dist:
13.5 kB: cli.js.gz
12 kB: cli.js.br
12.1 kB: microbundle.js.gz
10.8 kB: microbundle.js.br
Build "microbundle" to dist:
13.5 kB: cli.js.gz
12 kB: cli.js.br
12.1 kB: microbundle.js.gz
10.8 kB: microbundle.js.br
Long term, sure, but rolling our own will take a fraction of the time to land.
It's not exactly complicated functionality to stick an additional key into a sourcemap, after all.
@rschristian nods, valid. I guess I tend to have a default to a perfectionist mindset of 'do it right' (which often leads to scope creep 😅)
Hrmm.. getting a weird one while trying to test rollup
3.0.0
(+ related plugin bumps).
I'll keep looking, but have you ever run into this one before?
TypeError: brotliSize is not a function
It seems that this is coming from the babel transpiled code, where the import brotliSize from 'brotli-size';
is ending up with an object that contains a default
key, not actually getting the default import itself.
Also noticed that after bumping rollup
from 2.35.1
to 2.79.1
, some changes like the following are showing in the test snapshots; haven't looked deeper into what causes that change yet:
● fixtures › build visualizer with microbundle
expect(received).toMatchSnapshot()
Snapshot name: `fixtures build visualizer with microbundle 3`
- - Snapshot - 1
+ + Received + 1
- - import a from"camelcase";var o=a("foo-bar");export default o;
+ + import a from"camelcase";var o=a("foo-bar");export{o as default};
//# sourceMappingURL=visualizer.esm.mjs.map
Testing with the following command, and bumping just the version of rollup
:
sed -i '' 's/"rollup": ".*"/"rollup": "^2.35.1"/' package.json && \
git checkout package-lock.json && \
rm -rf ./node_modules && \
rm -rf ./dist && \
npm install --ignore-scripts && \
npm test
# Or for a quicker run: npm test -- --testNamePattern 'build visualizer with microbundle'
I got the following results:
rollup
2.35.1
doesn't have the change in default exportsrollup
2.36.0
has the change in default exportsPresumably it's related to the tree-shaking change? (or something not explicitly mentioned in the CHANGELOG?)
So next up is figuring out how to update the relevant fixture snapshots for this so that the tests are less noisy for the next version bumps. Which it seems I can do with a combination of:
Use this flag to re-record every snapshot that fails during this test run. Can be used together with a test suite pattern or with
--testNamePattern
to re-record snapshots.
Run only tests with a name that matches the regex.
⇒ npm test -- --updateSnapshot
After fixing the snapshots to account for the change from export default x
to export {x as default}
style that caused those test failures mentioned above; we can now try bumping all of the rollup
plugins.
Which then leaves us with the following failing tests:
Of which these can have their snapshots updated as they are just some basic CSS order changes/similar:
But these ones I need to look into more still:
For those babel ones, there have been a LOT of changes since @babel/preset-env
/ etc v7.12.10
; not sure if any of those are relevant to the error's we're seeing:
v7.15.0
(2021-08-04
) tov7.23.5
(2023-11-29
)
v7.12.10
(2020-12-09
) tov7.14.9
(2021-08-01
)
v7.12.10
)Also potentially tangentially relevant:
Might be related to autoprefixer
and/or babel
?
npm why browserslist
We should also have a closer look at the CHANGELOG for the following, and potentially try not bumping them fully to the latest versions:
rollup-plugin-typescript2
: because there was a seemingly tslib
related error@rollup/plugin-babel
: because there was a seemingly babel
related errorTS2354: This syntax requires an imported helper but module 'tslib' cannot be found.
The problem for me was that the editor was using a different TypeScript version than the project.
npm why tslib
You can see my exploratory WIP branch here:
I guess I tend to have a default to a perfectionist mindset of 'do it right' (which often leads to scope creep 😅)
I'd hesitate to call that the "right" way -- it's the inbuilt way.
Supporting this behavior by plugin doesn't come with any negative repercussions and in fact it'll allow users to continue to use Microbundle on older Node versions. There isn't an inherent need to connect the feature you want with upgrading Rollup in this case.
It seems that this is coming from the babel transpiled code, where the import brotliSize from 'brotli-size'; is ending up with an object that contains a default key, not actually getting the default import itself.
Usually means something's up with the CJS plugin, yeah. Odd, nothing in brotli-size
should be an issue from memory.
Also noticed that after bumping rollup from 2.35.1 to 2.79.1, some changes like the following are showing in the test snapshots; haven't looked deeper into what causes that change yet:
Terser, I believe. That's a better format, generally speaking, as more exports can be added with minimal size increase.
I'd hesitate to call that the "right" way -- it's the inbuilt way.
There isn't an inherent need to connect the feature you want with upgrading Rollup in this case.
@rschristian Fair. I guess my brain has already forked from the original task, and so the 'right' that I was referring to here was more about updating the 2-3 year old build tooling to modern versions than it was about the simplest way to implement the original desired change.
Supporting this behavior by plugin doesn't come with any negative repercussions and in fact it'll allow users to continue to use Microbundle on older Node versions.
@rschristian Also fair. Though I guess at this stage, I'm somewhat interested to see what other benefits can come from modernising the build tooling versions.
Usually means something's up with the CJS plugin, yeah. Odd, nothing in
brotli-size
should be an issue from memory.
@rschristian Yeah, debugging + inspecting it it definitely seems to be a case of the transpiled code not accessing the default properly. Still not sure why that is though.
That's a better format, generally speaking, as more exports can be added with minimal size increase.
@rschristian Good to know. It increased the size of most of the test snapshots by a few bytes, but for the two 'more real world' looking ones, the sizes actually decreased by a few bytes.
I've been updating the test snapshots as I go (after reviewing that it makes sense to do so) on my WIP branch:
I was referring to here was more about updating the 2-3 year old build tooling to modern versions
I'm somewhat interested to see what other benefits can come from modernising the build tooling versions.
I'm not sure there's going to be any improvements; Rollup hasn't changed much.
It increased the size of most of the test snapshots by a few bytes, but for the two 'more real world' looking ones, the sizes actually decreased by a few bytes.
From memory, I think they removed the logic to differentiate in these cases to instead just support the latter; the difference is small and the only ones adversely affected would be modules with a single default export, and only by a few bytes. Might not have been worth it on their end to support.
Splitting this off as a new issue so it can be tracked more easily. See the original issue for more context:
microbundle
is currently usingrollup
2.35.1
(2020-12-14
):output.sourcemapIgnoreList
(required to implement #1066) support was added in3.16.0
(2023-02-17
):Latest version (at time of writing) is
4.6.1
(2023-11-30
):