Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rollup-plugin-typescript] Re-enable declarationDir outside output file/dir #1772

Open
marekdedic opened this issue Sep 23, 2024 · 3 comments

Comments

@marekdedic
Copy link

Expected Behavior

Enable declarationDir to be outside the rollup output directory, much like it was possible in v11

Actual Behavior

Since v12, I get:

[!] (plugin typescript) RollupError: [plugin typescript] @rollup/plugin-typescript: Path of Typescript compiler option 'declarationDir' must be located inside the same directory as the Rollup 'file' option.

Additional Information

The change I'd like to be reconsidered was introduced in #1728. However, emitting declarations to a different place from the build output can be really useful for things like post-processing with api-extractor - having the intermediary declarations produced by rollup be outside the final output dir makes it much easier to not accidentally include these files in the final build.

@shellscape
Copy link
Collaborator

Thanks for the issue. I'd like to point out that the reproduction you provided is not valid, and that's not entirely cool since we lay out exactly what is.

On the subject matter itself, #1728 was a breaking change in how that worked and released as a major because of that. Moving forward, that's the intended behavior. What you're describing is the job of a post-processing task, which you elude to since you're using something like api-extractor. It would make sense that instead of error-prone output, post-processing moves build files to where they need to be in order to process them. This is extremely common in devops and deployments (much of what I do day to day).

I see a few possible paths forward for this use case:

  • intelligently handle/move build files where they need to be for additional processing
  • exclude appropriate files from final builds/packaging/deployment
  • write a rollup plugin to handle all or some of the above, which will run after plugin-typescript
  • open a PR which provides the capability you're requesting, without reintroducing problems previously associated with the capability prior to fix(typescript)!: correctly resolve filenames of declaration files for output.file #1728

This repo is almost entirely dependent on community contributions, so please understand that this may be something you have to affect to see it realized.

@stemcstudio
Copy link

I'd like to suggest that #1728 has introduced behavior that may not be intended. In order to determine whether this is actually the case, the relationship between the "file" option in the OutputOptions type in the rollup.config.* file and the "outDir" and/or "declarationDir" property in compilerOptions of the tsconfig.json file needs to be clarified. I have not been able to find relevant documentation for the plugin.

The fact that the rollup configuration supports multiple output files suggests to me that there is a conceptual issue with the relationship between these properties because the declarationDir property cannot simultaneously be inside many different directories implied by multiple OutputOptions.

@shellscape
Copy link
Collaborator

your argument may be valid, but in a specific context - yours, and a few others. the full request is it was written was to solve a problem that plagued the plug-in for a very long time and affected a lot of users. to that end, it's an effective solution. it's also a breaking change, which means you don't necessarily have to adopt the new contract.

that said, I'm sure we would all be open to a new pull request which satisfied the problem as it was resolved by #1728, and allowing for the use case which you view as correct.

if you'd like to discuss this until the cows come home, you're more than welcome to. but there's not going to be a one-size-fits-all solution unless the community steps up to make that happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants