rollup
Allow typescript transpilation not to match rollup file option
- Rollup Plugin Name:
@rollup/plugin-typescript - Rollup Plugin Version: migration from 12.1.4 to 12.3.0
Feature Use Case
We have a "complicate" rollup setup where we use rollup in phase one to output js and then use that output in step 2 to link code inside a worker. We also have a csp version that is simpler and doesn't need all this logic and output straight to dist folder. Code can be found here: https://github.com/maplibre/maplibre-gl-js/blob/c7ffb7469fb17e011733fc5c290dce21e544cdc9/rollup.config.csp.ts https://github.com/maplibre/maplibre-gl-js/blob/c7ffb7469fb17e011733fc5c290dce21e544cdc9/rollup.config.ts
This means that the two builds output to different folders, so I can't confiture a tsconfig to satisfy both. I know I can create a new tsconfig to inherit from the default one and then use it, but it's less than ideal.
Feature Proposal
If there's a way to make the build pass like it did for 12.1.x without changing any of the configuration files, that'll be great. But otherwise, if I could specify something in the rollup config so that it doesn't need to match the tsconfig that would be great.
If there's anything I can do to solve this easily, do let me know. Build is failing here:
- https://github.com/maplibre/maplibre-gl-js/pull/6621
Thanks for the issue. We've had this come up a few times, and we've had code changed to accommodate the different sides of this debate a few times. There's just not going to be a one size fits all solution on that, so we have to accommodate the most common use-case; which is unfortunately not what you're asking for here. The plugin is one of the most complex right behind node-resolve and commonjs. Combine that with a distinct lack of active maintainers on the plugin, and it's just not something that we would reasonably support atm.
The unfortunate best-case solution here would be to fork to meet your needs.
Thanks for the prompt response! I appreciate all the work put into this plugin. Are there any other options for me besides forking or adding a new tsconfig file? Is there a solution I'm not considering here?
If you'd like to spend time with the plugin and figure out how it can be modified to accommodate both approaches, I'm certainly open to taking a look at the proposal. IIRC it'll require quite a bit of rewiring. Only other suggestion would be to take a look at the issues and PRs related to the code path for that fix between the two versions that are causing your build failures. There may be some workarounds or more info in those issues.
FWIW the "fix" was admittedly a hard call on versioning because a fix for one could be a breaking change for others relying on the bug - which we have here. We just had one of those in commonjs last week. Depends on the arguments for/against a technical breaking change with the folks contributing at the time