-
-
Notifications
You must be signed in to change notification settings - Fork 614
chore: migrate rollup-plugin-babel #108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
packages/babel/src/index.js
Outdated
| }; | ||
| } | ||
|
|
||
| const babelPluginFactory = createBabelInputPluginFactory(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would gladly restructure this - I believe those should be 4 separate exports, rather than a single export with static properties. This PR will land v5 of this plugin so this is IMHO OK to do.
WDYT about those:
- default export (result of
createBabelInputPluginFactory()) createBabelInputPluginFactorybabelOutputPluginFactorycreateBabelOutputPluginFactory
Those named exports would be quite mouthful 🤷♂ but correct. I'm open for other names - but cant figure out anything better myself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the createXY names are ok as they will not be used often and only by people who know what they are doing. However I think functions should start with a verb, and the return value of createBabelOutputPluginFactory should be called getOutputPlugin, which also sounds less intimidating. For symmetry, I would furthermore export the default export additionally as getInputPlugin. This will make @TrySound happy 😃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought getBabelOutputPlugin and getBabelInputPlugin so that it does not conflict with other plugins
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also note that using named and default export together will switch the plugin to named-exports-mode when imported from CJS. This means that const babel = require(‘rollup-plugin-babel’) will no longer work. And I am not sure if the new CLI rollup -c —plugin babel would work. The latter could be fixed by providing a named export babel instead of a default. In any case, this change would be breaking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've changed exports to pretty much to what you have suggested, you can check out this commit: 4c5e1a8
remove ignore from preflight options
|
@NotWoods I've resolved your comments, could you take another look at this? |
NotWoods
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests look pretty good! Some links need updating.
The README and package.json should get updated to match the format of the corresponding files in other plugins. We're trying to use the same template for every plugin in the monorepo.
The CHANGELOG should have an entry for the change in package name and requirements. Other plugins have a similar entry you can copy.
The root README should also be updated with a link to the babel plugin 😄
|
@NotWoods resolved your comments, please take a look especially at the documentation changes. I still have some work to do, but in the meantime, I'd like to get "partial" approvals on what is already included here. My TODO list:
|
NotWoods
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changelog looks good! README needs a few tweaks to align with the other plugins.
|
@Andarist there seems to be a lot of pushback against conventions that we've set in the repo for migrating this plugin. the conventions we've chosen were to suit the various styles being brought in from repos that were very fragmented. so far, they've worked quite well to bring everything in line and have made maintenance much easier. If you'd like, I'm happy to go through and update the files that need updating to established conventions so we don't have to engage in the frequent back and forth. I'd like to get you on board, but perhaps it's better to have these discussions after the babel plugin is finished so we can complete the migration? the babel plugin is the last and only outlier, so the likelihood that we'll change the 23 other other plugins we've already completed migration for, before we complete the babel migration is pretty slim. |
cd63d3c to
98990a2
Compare
|
What's the status on this? |
|
@LarsDenBakker I'm going to pick up working on this next week. Would appreciate ideas on #108 (comment) |
Add repository
# Conflicts: # pnpm-lock.yaml
|
@rollup/plugin-maintainers after quite a long time, way longer than I've anticipated 😢, I've got back to it, resolved all comments, updated docs and changelog. This is no longer a draft from my perspective - I would appreciate a review 🙏 so we can move this forward and finally publish it as |
|
Thank you, and no worries on the time frame! I'll get to looking at this today! |
|
@Andarist I think we're good on this. I'll fix the pnpm conflict later today/tonight and then we'll merge. 🍻 |
This avoids fresh `pnpm install` problems where the build runs before babel plugins are installed.
|
@Andarist no matter what I try locally, I cannot get this to build: Please take a look. |
|
@shellscape fixed |
|
@Andarist I noticed that 5.0.0-alpha.2 was the latest version on rollup-plugin-babel, but the plugin here is only 5.0.0-alpha.1. I also didn't see that you were in an alpha stage, so I'm not sure how to release this because we should release a stable version to archive rollup-plugin-babel. I guess this is my fault for not looking at the old repo first. Please advise. |
|
Oh, sorry for not mentioning this recently - my intention was this to be a major bump, so just release this as 5.0.0 |
|
No worries at all. I'll do that tonight. |
|
Is this broken again? rollup/rollup-plugin-babel#360 I just tried making two outputs in Rollup, both with a plugin field with babel in them. Getting the same errors as in the issue above; "@rollup/plugin-babel": "^5.2.3" |
We don't know as you haven't really provided a repro case - there is a non-zero chance that you made some mistake. You could also try to actually debug the problem - the code is all there, on your machine, ready to be investigated. |
|
I have made a repro case that shows the same thing: https://replit.com/@stevage/rollup-plugin-repro |
|
@stevage you are using the input plugin in the output plugin's position. Please refer to this doc if you want to use the output plugin: https://github.com/rollup/plugins/blob/master/packages/babel/README.md#running-babel-on-the-generated-code |
Rollup Plugin Name:
@rollup/plugin-babelThis PR contains:
Are tests included?
Breaking Changes?
Description
This is still WIP and there is some work left to do regarding migration, but it's ready for a preliminary review. Other than that - I plan to include minor changes to the plugin before it gets released under
@rollupscope, so please do not publish this without my green light on that.I've managed to keep git history from the old repo, which I think is nice here - but it should be merged with squash here.