Plugin Updates: Questions and Discussion #1
Comments
|
I'll provide my take to kick this off. Any/all of these can be left alone and we can operate as the wild west - there's nothing wrong with that. This is more about getting these choices written down.
I leave this to the majority to decide.
Yes. This will provide a level of stability for plugins.
Yes. Consistency in CI will make maintenance less burdensome.
I leave this to the majority to decide. This is tricky. Not making a distinction raises the bar for bringing a plugin into the org. A higher bar might mean more work for the original author, or friction with any conventions, should we adopt any.
Yes.
Yes. Many other orgs have taken this path and it seems relatively frictionless. We should branch any repo which does this so critical fixes can be back-ported.
I think yes. There's benefit to keeping everything in-line. But I can see the benefit of leaving older, stable plugins alone at the same time. I leave this to the majority to decide. |
|
Here are my votes!
I say yes of course 😝 Maybe the best argument is it allows editors to show e.g. supported options in rollup config files. These files can get fairly complex... A middle ground to consider is allowing both .ts and .js with @ts-check.
+1.
+1.
+1 to just adopt prettier or some equivalent.
Org-owned go in the npm scope @rollup, user-owned are elsewhere.
+1.
+1.
Not sure about actively, but adopting a support policy that doesn't include unsupported Node versions would allow opportunistic improvements over time. |
|
I think using scopes ( I don't think we should, or that we have the power to, mandate that every plugin author uses TypeScript and adopts the same approach to testing/CI etc. We can encourage them to do so, and be rigorous about applying those standards to plugins in the org, but I think that's probably as far as we should take it. If we're striving for that degree of consistency, I wonder if it would be worth having a (Re CI — is anyone looking at GitHub Actions? I've heard good things...) |
|
Have also heard good things about Github Actions, but have not been invited to the beta yet. The monorepo idea is interesting. I don't have much experience setting them up (and I really don't want to be forced to use
Obviously those are all worst-case scenario. If none of us thinks those are concerns that we should be ... concerned... with, then I'm good with that idea. It would make juggling many of the standardization things listed in the OP a lot easier for sure. @guybedford @lukastaegert please chime in when you have a moment 😄 |
|
Thanks for taking the initiative here. Here are some of my two cents:
I think new plugins in the organization should be TS. There have been requests (and contrubtions) from the community to add types to node-resolve and commonjs, but being TS from the start would make these things much simpler. We could discuss how we want to manage typings for the JS builds. Having a public d.ts file that is copied into the dist folder worked very well for rollup and rollup-pluginutils (and provides probably the smallest possible amount of typings for JS builds), but there are other approaches like rollup-plugin-dts that we might want to take a look at. On the other hand, it would be nice to have a sample JS approach for plugins that are not important enough to be converted so they still fulfill certain standards.
Certainly for organization owned plugins. Open questions are what framework. Rollup itself uses Mocha, which works well with the thounsands of directory/sample based tests we have there. rollup-pluginutils uses Jest, which I think may work better for plugins. However the parallelization of Jest does not really kick in with the sample-based test approach as for Jest, everythings is basically part of the same test file and parallelization only occurs between different files. We could, however, consider changing the sample file format of the Another point here is that test-suites in plugins should use the
Definitely.
Absolutely! Everyone should be encouraged to write plugins the way they like, the more the merrier, even if this causes some friction for users. To mitigate that, org-owned plugins should be highlighted sufficiently. However to help people meet certain standards, it could be helpful to provide tools/boilerplate etc. so that people can build plugins that meet the official standards so that such a plugin could be easily added to the organization. And we should encourage people to use that if they want to have a chance that their plugin becomes official. I remember that this is an approach that ESLint follows, where you get basically a free test setup and boilerplate if you create a plugin repo the official way.
Maybe this could be like: New major versions that meet our standards highlighted above, so that the
I think org-owned plugins should be in-sync with the version supported by Rollup. At the moment this is still Node 6 (and I remember there always happen to be some Linux users that for some weirds reasons are stuck on old distros), but there should be a major this year that switches to Node 8. I also think that plugins should use the latest JS code + transpilation, either by setting the TypeScript target accordingly or adding a Babel setup with babel-plugin-env (I think node-resolve/commonjs do that at the moment). Then when a new major Rollup version is released, when can easily release new majors of the plugins that have the new Node version as target. As for the monorepo discussion, I am slightly in favor with the caveat that plugins in the monorepo should be considered critical to the ecosystem. At the moment, this is mostly node-resolve and commonjs but we could certainly talk about others. Download statistics could be a guide here. However, commonjs is in my opinion in a very sorry shape. I find the code nearly impossible to understand with its long winded functions, few abstractions and complicated dependencies. It might be worthwhile to start a rewrite that focuses less on tree-shakeability and more on correctness. @guybedford had some ideas what the wrapper code could look like. The big advantage I see is having a combined test-suite that also checks if new Rollup fixes break plugins. Also we can do combined releases. |
I'm in slight disagreement with this. Users are given an incredible amount of runway (upwards of a year) to prepare for the drop of a Node version from LTS, and with the Active LTS status, that time frame doubles. Continuing to support out-of-LTS versions is a hamstring to the project(s). Most of the major ecosystem projects drop out-of-LTS versions very quickly after their expiration. I'm a bit of a semver purist, and don't feel bashful about a new major number any time there's a breaking change - even if there aren't any patch or minor releases between majors. While I don't necessarily agree with the Rollup core's approach to waiting on that transition, we've got the opportunity for a fresh start for the plugins, and my vote would go towards keeping plugins on the LTS path. We also don't have the requirement, nor contribution level, that plugins are versioned to core (such as Babel).
That blurs the lines a bit. Asking everyday users to parse which are mission critical and which aren't is asking a bit too much. I think it'd be easy to highlight that in a README, which maintainers will pick up on pretty easily. We've got 27 plugins that have been maintained by the org at one point in time, so the precedent is there that they're org-supported. Unless we want to deprecate some of them, I believe they should all go into the monorepo, should we use one.
I've actually written a script to query NPM for user-owned third-party modules, based on download counts, that we should approach to bring into the org. Will keep everyone posted about that. |
If this includes plugins that Rollup depends on, then this would force Rollup core to update anyway or stick with outdated version as otherwise the tests will no longer run. I am not against switching the version sooner than later but against pushing a major just for the Node update and another for the next "small" breaking change. At the very least, all currently deprecated features should be removed as well and all features marked for upcoming deprecation should have their deprecation warnings switch on for all users. Plus it would be nice if someone wrote a few words about the next major release because major releases tend to get featured e.g. in "JavaScript Weekly" The thing is, there is little disadvantage to sticking with Node 6 at the moment. The only big feature that is transpiled is async await, which is replaced with a generator syntax that is still very efficient and has nice error stacks. My suggestion is to make this and any future switches for plugins as painless as possible by either using TypeScript directly or including Babel, at which point switching is a matter of changing a line in configuration. There would be no syntax restrictions in what plugins can use and only some restrictions with regard to prototype properties on builtins, but there weren't too many new ones after Node 6 AFAIK. |
That's a good point. We can use Rollup as a |
|
Before jumping to @shellscape questions, I would like to echo @Rich-Harris comments on going with a mono-repo approach. It's a fantastic way to ensure consistency in tests, code style, linting, and even opens up possibilities for creating interesting and helpful e2e and integration tests. We also ensure that all of our plugins have a consistent dependency tree and can quickly resolve issues with security audits and nasty bugs. You can still have independent release cycles and versions between the plugins even though they are in a shared monorepo. That said, here's my take on @shellscape questions...
Yes, we could argue for days about the advantage/disadvantages of TypeScript, but as library maintainers, the choice becomes much more clear. If we want to present a consistent and unified platform for developers to use, we should go all-in on TypeScript. While initially only adopted in the Angular (2+) community, it is gaining popularity in the React and Vue communities. Users are coming to expect that 3rd party libraries and tools are in TypeScript as they are writing their code in TypeScript. In addition, there will most certainly be non-official DefinitelyTyped type definitions cropping up, and we want to be heading that off at the pass by writing in TypeScript in the first place.
Yes, this will ensure reliability and build trust with our user base.
+1
Yes, plugins should use and enforce
Yes. Should it be that org-owned plugins exist in the scoped packages and user-owned plugins do not? If we go mono-repo, org-owned plugins live in the MR and user-owned do not.
Yes definitely.
So are we saying adopt a roll-over approach? Scope them as breaking changes are made? It makes sense to me.
Yes, this adds a level of technical debt, maintenance and overhead. Nice to meet ya'll. Looking forward to working with you. |
|
We've started the process! Going to close this in favor of rollup/plugins#2 |
Rollup isn't going anywhere, and if anything is gaining steam month over month. Bringing the plugin ecosystem inline and to a common standard will be helpful for maintaining the org long-term. Rollup currently maintains 27 plugins.
Questions
¹ org-owned plugins are defined as those plugins which originated in the org, rather than being transferred in by the original author
Plugins
Below is a list of all plugins currently within the org:
We'll use the list above to track updates according to the general consensus here.
@rollup/core let's discuss these questions
The text was updated successfully, but these errors were encountered: