Plugins: Plugin Migration

[shellscape]

Below is the big-ass list of plugins that need migrating into this repo:

Done

• [x] rollup-plugin-alias
• [x] plugin-auto-install
• [x] rollup-plugin-buble
• [x] rollup-plugin-commonjs
• [x] rollup-plugin-dsv
• [x] rollup-plugin-image
• [x] rollup-plugin-inject
• [x] rollup-plugin-json
• [x] rollup-plugin-legacy
• [x] rollup-plugin-multi-entry
• [x] rollup-plugin-node-resolve
• [x] rollup-plugin-replace
• [x] rollup-plugin-run
• [x] rollup-plugin-strip
• [x] rollup-plugin-sucrase
• [x] rollup-plugin-typescript
• [x] rollup-plugin-url
• [x] rollup-plugin-virtual
• [x] rollup-plugin-wasm
• [x] rollup-plugin-yaml

Misc

• [x] rollup-pluginutils

In Progress

• [x] rollup-plugin-babel _(in progress @Andarist)_

Pending

Skip

• [x] rollup-starter-plugin
• [x] rollup-plugin-butternut _(deprecated in favor of terser)_
• [x] rollup-plugin-node-builtins _(was an empty repo, plugin owned by third party)_
• [x] rollup-plugin-ractive _(Ractive is a dead project)_
• [x] rollup-plugin-svelte _(will be transferred to @sveltejs)_

Before we move a plugin we should:

• [ ] Follow up on any open issues.
• [ ] Follow up on any pending Pull Requests.
• [ ] Add note to the README about the move
• [ ] Disable issues and Pull Requests

_Give n number of days for response based on age of issue/PR, if there is a reproduction provided, etc._

For each plugin we should:

• [ ] Assert there are tests
• [ ] Apply linting and clean the code
• [ ] Update aged dependencies
• [ ] Remove unneeded metadata covered by the monorepo
• [ ] Create an issue label for the plugin

After moving a plugin we should:

• [ ] Put the plugin repo into an archived state
• [ ] Add a deprecation notice to the README and provide URL to the monorepo path for the plugin
• [ ] Publish a patch version with the deprecated property added to package.json.

[lukastaegert]

Would we want to mandate TypeScript for the Monorepo? I know this would severely slow down the migration, but in the end it would make the monorepo more consistent.

Missing from the list IMO: rollup-pluginutils

[lukastaegert]

It would also mean that people can expect all @rollup/ plugins to have types. Alternatively we could say: Monorepo plugins should either be TS or at least have TS types, what do you think?

[wesleygrimes]

I think we should mandate TypeScript for all plugins. I need to get look at some of these plugins in more detail to get a feel for it, but we should be able to infer a lot of the types.

[wesleygrimes]

I don’t like the idea of adding on types as these quickly get stale as new features are built and it’s another set of technical debt that must be maintained.

[lukastaegert]

I think we should mandate TypeScript for all plugins. I need to get look at some of these plugins in more detail to get a feel for it, but we should be able to infer a lot of the types

Definitely my preferred option as well.

[lukastaegert]

If we go for TypeScript, I would also throw in the suggestion to use TypeScript in tests as well. Just another safeguard that tests do not become stale.

[wesleygrimes]

If we go for TypeScript, I would also throw in the suggestion to use TypeScript in tests as well. Just another safeguard that tests do not become stale.

Agreed! I’ve used Jest and Jasmine in the past. I prefer Jest, but it looks like everyone is preferring Ava here. I am fine with that if you all think it works well.

I do love how Jest has a lot of built in helpers like test.each, etc...

[lukastaegert]

In the end, a lot of test are probably directory/sample based, meaning that the test file fs.readFileSyncs a directory where each folder corresponds to a test and has a special structure, usually with a _config.js file for fine-tuning. For those tests, helpers provided by the test framework will not help anyway. We could of course attempt to change the structure of those tests so that the config files become valid test files but the current approach reduces boilerplate to the minimum. As an example, you could check out the tests of rollup-plugin-commonjs.

What I am saying is: I love Jest as well, but in the end, it will probably not matter too much.

[wesleygrimes]

Cool, I’m good with that. I will trust your judgment on these things as I am newer to the rollup ecosystem. Looking forward to learning Ava to be honest. It looks nice and clean.

[shellscape]

I would go so far as to say that I don't want to take on so much as to slow down this re-organization. That being said, a lot of these tasks can be delegated as long as we have a few folks poking at this (which it looks like we will). Converting non-TS plugins to TS should be the final step. No reason why plugins that don't already have tests (e.g. auto-install) shouldn't have theirs written using TS either.

Getting the ball rolling is more important than asserting TypeScript at every step imho, but I would not recommend we publish any new major versions until TS has been implemented.

[wesleygrimes]

That's the great thing about TypeScript too, we can just rename the files to .ts and immediately "profit", then as we see fit start adding types. This is because JavaScript is valid TypeScript.

[Andarist]

I would be interested in migrating rollup-plugin-babel (which I maintain) to the monorepo. I'm wondering if there is a plan to create a bot or smth that would ping "code owners" of the particular plugin? With many plugins inside a monorepo it might be harder to tackle all issues - I would like to focus mainly on babel-related ones but getting notifications about whole repo and filtering them on my own is rather a blocker for me. I'm just having too many notifications from GitHub already and I can't handle more than that.

[shellscape]

@Andarist wonderful. I'll add you to the Plugin Maintainers team shortly. Please follow the same pattern of opening a PR that we've been using so far. The process is still very manual at the moment. I and the other maintainers will be happy to pitch in on the effort.

We're planning on tagging issues with plugin-specific tags, and all issues templates require the associated plugin's name, so hopefully it'll be easy to divine. A bot to manage notifications per plugin is a great idea. Alternatively, you could filter out any notification emails that didn't pertain to the plugin(s) you're interested in. That's relatively trivial to do with Gmail, not sure about other email providers.

[Andarist]

I'll get to migrating in the following weeks - need to wrap up some other OSS work now though and handle all issues/PRs in the rollup-plugin-babel before migrating.

[btd]

@shellscape i can help with rollup-plugin-inject.

[shellscape]

@btd that's great, thank you. I'll be adding you to the Plugin Maintainers shortly. Please follow the same patterns / procedures as the other Pull Requests for migrating.

[osdevisnot]

@shellscape I can help with plugin-auto-install. From auto install, here is the todo items filtered from your list:

• [x] Follow up on any open issues.
• [x] Follow up on any pending Pull Requests.
• [ ] Add note to the README about the move
• [ ] Disable issues and Pull Requests
• [ ] Assert there are tests
• [ ] Apply linting and clean the code
• [x] Update aged dependencies
• [ ] Remove unneeded metadata covered by the monorepo
• [ ] Create an issue label for the plugin
• [ ] Put the plugin repo into an archived state
• [ ] Add a deprecation notice to the README and provide URL to the monorepo path for the plugin
• [ ] Publish a patch version with the deprecated property added to package.json.

Also, it seems plugin-auto-install is already published under @rollup namespace. So this package won't need a new publish.

[santoshyadavdev]

Anything I can help with?

[shellscape]

@santoshyadav198613 absolutely! If you'd like to help migrate a plugin, please choose one in Pending and follow the same pattern as our other migration Pull Requests (#6, #7, #11 or #15)

[santoshyadavdev]

Thanks @shellscape ,
I will start with plugin-auto-install, looks like already taken, will go with rollup-plugin-butternut.

[shellscape]

Great, I'll mark it down above.

[santoshyadavdev]

@shellscape will take rollup-plugin-commonjs next

[santoshyadavdev]

Hi, @shellscape As the earlier plugin is already deprecated will start working on rollup-plugin-commonjs please add it on my name.

[thgh]

I'm interested in migrating node-resolve, PR incoming

[shellscape]

@thgh many thanks for that!

[pnevares]

I'd love to help migrate rollup-plugin-url!

[wuweiweiwu]

I can pick up rollup-plugin-node-builtins and add rollup-plugin-terser to this list! cc @TrySound

[TrySound]

I'm still processing this.

[shellscape]

@pnevares please do!

@wuweiweiwu that would be wonderful, thank you.

@TrySound no rush my friend 👍

[Shriram-Balaji]

@shellscape I'd like to help migrate rollup-plugin-run

[shellscape]

@Shriram-Balaji please do!

[NotWoods]

@shellscape I can work on migrating rollup-plugin-legacy

[shellscape]

@NotWoods perfect. The recent yaml plugin PR is a great benchmark to compare against.

[Kocal]

Can we add rollup-plugin-graphql to this repository?

I know that it's not an _official_ (I mean not maintened by Rollup team) Rollup plugin, but GraphQL is a well used language and this plugin is not compatible with Rollup ^1, an PR has been opened since more than 1 year (https://github.com/kamilkisiela/rollup-plugin-graphql/pull/7) but it's not merged.

So I've forked the package, applied @bennypowers's patch, added mutli-export support (https://github.com/Kocal/rollup-plugin-graphql/commit/d699178a1f4b82dad59a13dd2e89e0a610658a3e), and published the package to @kocal/rollup-plugin-graphql.

But that's not an ideal solution... GraphQL is well used and I think it would be nice to import it here.

What do you think? Thanks!

[shellscape]

@Kocal (let's open new issues for questions like this in the future) this is tricky. We want to license all of the official plugins to the Rollup org, so to get any third party plugins into the org as an official, the author has to transfer it to the org and also update the LICENSE file. That's the only legit way to do it.

Now, that doesn't preclude us from writing a _new_ plugin with _similar_ functionality and crediting the original author for ideas. But that has to be a completely new, from scratch, original piece of work, even including tests. Rewrites often fall into this category. So I would track down the author on twitter and/or open an issue asking about transferring to Rollup and relicensing, or start a new work. Given the age and lack of activity on the project, a new work might make more sense.

[NotWoods]

@shellscape I can work on migrating the code for rollup-plugin-typescript

[shellscape]

That's great news. I'll ping you when it's prudent to start. We've got to get that repo tidy before we start. Lots of pending PRs that I'd like to give people time to respond to. I'll start closing them as abandoned later in the week.

[evanplaice]

Are there any unclaimed plugins left? I'd like to help.

[shellscape]

@evanplaice awesome, thank you. yessir. sucrase and legacy are still pending, as is babel - even though those are "claimed." Until there's a PR for them, they're fair game.

[Andarist]

I'm going to start working on babel migration soon - was occupied by some different stuff lately and also were iterating through a PR to the rollup-plugin-babel with Lukas, so it was not the right time to start preparing a migration.

[pajaydev]

@shellscape Awesome work. This is great for ppl wants to contribute. Is there any pending plugins I can take ?. Happy to help 😃

[shellscape]

@pajaydev thank you, it's a team effort!

We pretty much have the migration down to the last few and in progress. We're migrating bugs and issues over from the old repos that are still relevant and would absolutely love some help with those!

[pajaydev]

@shellscape Thanks. I will take a look.

[vladshcherbin]

Hey 👋

In after moving todo list there is "Publish a patch version with the deprecated property added to package.json", however I don't think this property is added.

For example, take node-resolve plugin:

• from github readme you can find it's deprecated
• from npm readme you can't see any deprecation because package was not updated and readme is from latest version
• when you install this plugin, it also doesn't give you any deprecation info

It would be really great to actually have patched versions with deprecation notice 🙏

[shellscape]

@vladshcherbin we'll get there. Npm permissions for a lot of these plugins require author action, and it doesn't always happen fast. We ask for patience.

[shellscape]

@vladshcherbin would you be interested or open to moving rollup-plugin-copy here?

[vladshcherbin]

@shellscape sure

[matt3224]

+1 for rollup-plugin-terser

[shellscape]

@matt3224 I think at this point that @TrySound prefers to keep that project under his personal account, and we respect that decision. That said, we'll always be open to hosting it here.

[wuweiweiwu]

@vladshcherbin I can help migrate rollup-plugin-copy if you don't mind!

[abdonrd]

There are any news about the @rollup/plugin-copy? Thanks in advance!

[shellscape]

@abdonrd use it at rollup-pugin-copy.

[shellscape]

Babel is migrated. We're done! Huge thank you to everyone that was involved in this effort!