Closed rschristian closed 1 year ago
I like the simplicity this would provide, but it would also drop const inlining and const enum support which are really important for libraries.
Bah, yeah forgot about that late last night as I wrote this up.
I'm guessing the Babel imitations of those features (where they exist, anyhow) aren't compelling or without enough coverage? Admittedly I dodge those TS features myself so I'm rather unfamiliar.
Well, going to close this out as I think it's a wash. I wonder if any other tools handle this nicely. I'll poke around, maybe just patch microbundle I suppose.
Our current setup passes TS & TSX through
rollup-plugin-typescript2
before passing those assets onto Babel, which creates a point of frustration: there's an inconsistent UX that's built upon whether a user is authoring in TS or JS. For example, it's not possible to run a Babel plugin against TS or TSX as it'll already be transpiled by the time Babel gets it. I have to choose between my nifty plugin that does some JSX attribute manipulation or authoring in TS(X) as I cannot have both.I therefore propose we drop using
rollup-plugin-typescript2
for anything but generating types.This creates a more consistent tooling pipeline, should simplify some things (we mirror a few flags between Babel and the TS plugin), and it should come with a bit of a speedup, as
rollup-plugin-typescript2
does usetsc
under the hood (albeit with a few neat things to try to speed it up).