Migrate Rollup TS Plugin to '@wessberg/rollup-plugin-ts' to support async rollup plugins #200
Description
Current Behavior
TSDX uses rollup-plugin-typescript2 to compile and check TypeScript files. Due to certain anomalies specific to this plugin, tsdx users are unable, inter alia, to use additional rollup plugins that contain async/await syntax (e.g., rollup-plugin-visualizer) without a workaround. See ezolenko/rollup-plugin-typescript2#105; see also #183 (comment).
Unfortunately, the workaround, aptly titled, objectHashIgnoreUnknownHack, 'can potentially make cache stale,' due to the fact that rollup-plugin-typescript2 uses a hash of the entire rollup configuration to facilitate cache invalidation. See ezolenko/rollup-plugin-typescript2#105 (comment). As a workaround for the workaround, users are encouraged to bypass the cache completely by setting clean to true in their rollup configurations. See ezolenko/rollup-plugin-typescript2#105 (comment).
The plugin uses rollup config as part of cache key. object-hash is used to generate a hash, but it can't hash certain elements at the moment. Setting this option to true will make object-hash ignore unknowns, at the cost of not invalidating the cache if ignored elements are changed. Only enable this if you need it (Error: Unknown object type "asyncfunction" for example) and make sure to run with clean: true once in a while and definitely before a release. (See #105)
Desired Behavior
As a tsdx user, I should be able to extend tsdx's rollup configuration to include additional plugins that use async/await syntax without a workaround and, especially, without having to worry whether my cache is stale.
Suggested Solution
Replace rollup-plugin-typescript2 with rollup-plugin-ts.
Who does this impact? Who is this for?
While #183 added support for extending tsdx's rollup configuration, making it easy to add additional rollup-plugins, there is no easy way to swap out tsdx's default plugin choices. See, e.g., infra, Alternative Solutions. Thus, tsdx users are, more or less, blocked from using any rollup plugin that contains async/await code. As the async/await syntax continues to gain popularity, it is likely that this issue will affect more and more tsdx users.
Describe alternatives you've considered
With #183, tsdx users can hack tsdx's default plugin choices (example below) to either (1) to modify the rollup-plugin-typescript2 configuration as described above, or (2) swap out the plugin for rollup-plugin-ts; however, neither approach is ideal.
const ts = require("@wessberg/rollup-plugin-ts");
module.exports = {
rollup(config, options) {
config.plugins = config.plugins.map(plugin => {
if (plugin && plugin.name === "rpt2") {
return ts({
tsconfig: tsconfig => ({
...tsconfig,
target: "esnext",
sourceMap: true,
declaration: true,
jsx: "react"
}),
transpiler: "babel"
});
}
return plugin;
});
...
return config;
}
};
For diagnostic purposes, a working example using the above swap-out hack can be found here: https://github.com/medelman17/tsdx-monorepo-template
Additional context
The rollup-plugin-typescript2 plugin appears to have several additional bugs that may cause tsdx users pain. For example, to enable code splitting, users must also employ an additional workaround, setting rollupCommonJSResolveHack to true. But see:
On windows typescript resolver favors POSIX path, while commonjs plugin (and maybe others?) uses native path as module id. This can result in namedExports being ignored if rollup happened to use typescript's resolution. Set to true to pass resolved module path through resolve() to match up with rollup-plugin-commonjs. rollup-plugin-commonjs fixed this in 10.1.0, so projects using this option who update to new version will be broken again. This also works around the similar bug affecting code splitting (see rollup/issues/3094).