Releases: wessberg/rollup-plugin-ts
v3.1.0
v3.0.2
- chore: bump deps 6c96c17
- feat: add support for ESM-based Babel configs. Closes #167 15e8edd
- feat: add support for multiple swc configs. Closes #177. Don't enforce importHelpers: true to avoid a potential tslib error when babel or swc is used for all types of syntax 5ba4c9c
- fix: don't call addWatchFile outside of allowed Rollup phase 8b3e7e8
v3.0.1
v3.0.0
New Features
rollup-plugin-ts is now based on ESM and requires Node v14.19.0 (BREAKING CHANGE)
Now that TypeScript v4.7 is out, it has finally received great support for ES modules in a Node.js environment that aligns with how it has been implemented across Node.js and browsers.
Because of this, now is a good time to make this plugin a type: "module" package. However, it still provides a CommonJS fallback. If your codebase is still based on CommonJS, you should be fine. Please know however, that rollup-plugin-ts requires an environment running Node v14.19.0 or newer going forward.
TypeScript v4.7 support
rollup-plugin-ts now fully supports TypeScript v4.7 and its new features.
This also means that you can now use .mjs, .mts, .cjs, and .mts files.
Additionally, the extension of your declaration files will depend on the extensions of your output files as controlled by your Rollup config:
.jsoutput files will produce.d.tsand optionally.d.ts.mapfiles.mjsoutput files will produce.d.mtsand optionally.d.mts.mapfiles.cjsoutput files will produce.d.ctsand optionally.d.cts.mapfiles
Transpilers are now used for the entire syntax transformation (BREAKING CHANGE)
Before, when you selected a transpiler such as babel or swc, these wouldn't actually be used for stripping away TypeScript-specific features such as types, enums, and decorators. Instead, the TypeScript compiler APIs would still be used for performing the initial syntax transformation, and then babel or swc would "take over from there". However, there are times when you may want to use babel or swc even for the initial transformation.
Going forward, a transpiler will be used for the entire syntax transformation. However, this can be easily customized by mixing transpilers, which is an easy way to get the old behavior back.
Transpilers can be mixed
Now, the transpiler plugin option also accepts an options object if you want to mix them:
ts({
transpiler: {
typescriptSyntax: "typescript",
otherSyntax: "babel"
}
})This allows you to decide exactly which transpilers are responsible for which parts of the emit phase. If you want to, in principle you can decide to let swc strip away TypeScript syntax, and then let babel continue on from there. You're in full control.
Of course, it still supports simply accepting a string, like always.
v2.0.7
v2.0.6
- feat: add support for target ES2022 6eec842
- feat: add TypeScript v4.6 support c387ff7
- feat: generate correct declarations, diagnostics, and .tsbuildinfo when a Rollup cache is being used. Fixes #140 afa76ed
- fix: correctly add aliased re-exported bindings to lexical environment at all times. Fixes #109 16d24fa
- fix: correctly alias re-exported bindings which themselves may be aliased from other source files from the same chunk. Closes #176 364b50b
- chore: run tests on Node v14, 16, and 17 619f7c4
v2.0.5
- chore: bump dependencies 6061f60
- fix: don't break when another plugin declares an asset that only later receives a source. Fixes #162 3ec4c86
- feat: when using swc and no browserslist could be resolved, pass the ecma version directly as a target instead of generating a browserslist based on it. Closes #163 a2e88e5
- Merge pull request #159 from hewel/fix-swcConfig 724e204
- fix: swc reject when set parser to typescript 3770470