TypeScript plugin enhancements

[NotWoods]

• Rollup Plugin Name: typescript
• Rollup Plugin Version: 2.0.1

Feature Use Case

Our current official TypeScript plugin is missing a few important features:

• Cannot generate type definitions
• Cannot handle emit-less types
• Cannot report typing errors

As we prepare to rewrite our plugins in TypeScript we should make sure that we offer a great plugin too.

Feature Proposal

There are many Rollup TypeScript plugins in the community and we want to incorporate them rather than re-inventing the wheel. Our plugin uses TypeScript's simple API that just removes types. Other plugins call the command line API or use TypeScript's more complex compiler API.

rollup-plugin-ts looks like the best option for us. It handles lots of edge cases and is well maintained. It's great that its well tested (with Ava too!), emits declaration files for each chunk, and properly emits type errors.

The plugin also has lots of extra features, so we may want to keep some core functionality and leave some of the additional features in the user-land plugin.

• browserslist can be used instead of target.
• Babel can be used instead of TypeScript. (Sucrase can also handle the use case of just stripping types with no checks.)

@wessberg, would you be interested or open to moving rollup-plugin-ts here? How do you think we should proceed?

[wessberg]

Hi there. Thanks for considering rollup-plugin-ts, I'm thrilled that you think it would be a great default Typescript plugin for Rollup.

As you also touch upon with the point about extra features, it isn't exactly a minimal Typescript transpiler, it is more of an orchestrator of the relationship between Rollup, Typescript, Babel, and Browserslists, all powerful tools in their own rights. Today, there's several Babel and TypeScript rollup plugins to choose from, but I think the only way to make the relationship great is by handling them both from the same plugin. I cover some of this in more detail in the FAQ,

For rollup-plugin-ts to be a default TypeScript plugin for Rollup, it would need to be less opiniated and less batteries-included which I find to be one of the plugins great strengths. I do consider moving its (arguably) most popular feature - declaration bundling with code splitting support - into a separate library that other plugins can rely upon, but other than that, I'm not sure how much more granular it can be without losing its appeal.

I'm not open to moving my work on rollup-plugin-ts to the monorepo for these reasons, but also for others, including that I'm actively seeking sponsors and Patreons to support my open source work.

What I would suggest as a path forward is for Rollup to not have an official TypeScript plugin at all, and instead point to community packages such as rollup-plugin-ts or rollup-plugin-typescript2. Alternatively, I'll gladly serve as a guide to the best of my abilities and provide code reviews, suggestions, etc, should you decide to write a Typescript plugin yourselves.

[shellscape]

@wessberg thanks very much for responding here. I wanted to touch on a few things, only to provide context.

What I would suggest as a path forward is for Rollup to not have an official TypeScript plugin at all

That's not an option for us unfortunately. @rollup/plugin-typescript is considered a core-critical plugin, and it's essential that we maintain it as rollup core depends upon it. One of the reasons for putting the monorepo together was so we could get core-critical plugins back to an actively maintained state.

and instead point to community packages such as rollup-plugin-ts or rollup-plugin-typescript2

Because of the afore mentioned core-critical status, we're probably not going to be recommending a community plugin as a default, at least not at the moment. typescript2, for all of it's benefits, is terribly slow to the point of being unusable on newer versions of TS.

Grouping a few quotes together here:

that I'm actively seeking sponsors and Patreons to support my open source work
it is more of an orchestrator of the relationship between Rollup, Typescript, Babel, and Browserslists, all powerful tools in their own rights
For rollup-plugin-ts to be a default TypeScript plugin for Rollup, it would need to be less opinionated and less batteries-included

Absolutely understandable that you'd want to boost your income for open source. I try to do the same - though I'm only up to a whopping $9 a month (hey, that's a 6 pack of beer right? not bad). However - and I say this with with positive intent only - what our job is as part of Rollup and specifically in this repo is to lift up the greater Rollup community as a whole. The last two quotes there touch on why that's important; it would be a boon to the community at large if the individual plugins for TS, Babel, and Browserlist (is there one?) worked in better harmony, but were also able to be used separately. Unbolting rollup-plugin-ts and working in the bits that make everything play nicely would be huge. So that's what we were going for in bringing you in on the discussion.

Alternatively, I'll gladly serve as a guide to the best of my abilities and provide code reviews, suggestions, etc, should you decide to write a Typescript plugin yourselves.

That's a wonderful, generous offer, and we'll definitely take you up on this. I think what we're going to need some feedback and teamwork on moving forward in the near future is how to prevent our current TS plugin, @rollup/plugin-typescript, from stepping on the toes of rollup-plugin-ts. It's inevitable that as we improve @rollup/plugin-typescript over the coming weeks/months that we may see similar (or the same) features and additions, and we're going to want to maintain harmony with you on that.

[paulrostorp]

What is the status of this ?

[NotWoods]

Very close to being ready! Once #162 is merged I'll put up a PR adding typechecking to the plugin 😄

[NotWoods]

@rollup/plugin-typescript version 3.0.0 will have typechecking and support emit-less types, so I'm going to close this ticket. #61 will track generating .d.ts files.

[christopherthielen]

@NotWoods should #61 be unlocked if it's going to be used to track emitting types?

[NotWoods]

Yes, it was probably left locked by accident. @shellscape can you unlock it when you have a chance?