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

Support non-ambient ".ts" modules #31

Closed
aleclarson opened this issue Jun 5, 2019 · 4 comments · Fixed by #32
Closed

Support non-ambient ".ts" modules #31

aleclarson opened this issue Jun 5, 2019 · 4 comments · Fixed by #32

Comments

@aleclarson
Copy link
Contributor

aleclarson commented Jun 5, 2019

I'm curious why support for non-ambient (eg: .ts not .d.ts) definitions was removed.

I don't want this plugin to emit anything other than the .d.ts bundle, but it would be nice to avoid generating intermediate .d.ts modules. Also, with ts-loader and awesome-typescript-loader, it's not possible to generate .d.ts modules if you want to use a forked process for type checking (eg: with fork-ts-checker-webpack-plugin).

To be clear, I don't want this plugin to perform type checking, either.

@aleclarson
Copy link
Contributor Author

aleclarson commented Jun 5, 2019

I just realized the dumbness of mentioning Webpack plugins in an issue about a Rollup plugin. 😂
I must've confused myself temporarily, but the issue still stands. I would like to avoid intermediate .d.ts modules if possible. Otherwise, I'll need to figure out how to emit .d.ts modules with rollup-plugin-typescript2 before running this plugin.

Maybe there's a way to feed the .d.ts modules generated by rollup-plugin-typescript2 into this plugin?

@aleclarson aleclarson changed the title Support non-ambient entry points Support non-ambient ".ts" modules Jun 5, 2019
@Swatinem
Copy link
Owner

Swatinem commented Jun 5, 2019

I gave my reasons in #29. In short, using the typescript compiler for anything else than just as a parser is really not-trivial.
And I don’t want to put in all the duplicated effort into supporting all the different ways how people want to build/manage their projects (like #28).
Easiest way is to delegate that task to other tools, such as the tsc cli itself.

For me personally the transition was really easy and smooth, see 7ea4a02 and eversport/intl-codegen@412f1bf

This also opens up the door to maybe kick out ts-jest as well at some point, since it starts to really annoy me recently. Also, as you see, I don’t need any plugin/loader anymore to bundle up my .js code anymore. Which is a win. So instead of N tools, each of which is different in some subtle ways, and supports a different set of features (like --incremental or project references), I try to rely on tsc only, without any other third party tools that could potentially break in surprising ways.

@Swatinem Swatinem closed this as completed Jun 5, 2019
@aleclarson
Copy link
Contributor Author

In short, using the typescript compiler for anything else than just as a parser is really not-trivial.

It's not easy to generate ambient declarations from a set of .ts modules, and then feed those directly to rollup-plugin-dts to escape the need for intermediate files?

And I don’t want to put in all the duplicated effort into supporting all the different ways how people want to build/manage their projects

Sure, but I don't see this as a slippery slope. All I want is to avoid intermediate files. :)

@Swatinem
Copy link
Owner

Swatinem commented Jun 6, 2019

All I want is to avoid intermediate files. :)

I thought the same some months ago, now I changed my mind about this :-)

aleclarson added a commit to aleclarson/rollup-plugin-dts that referenced this issue Jun 6, 2019
This compiles ".ts" modules into ".d.ts" modules in-memory and forwards them to Rollup.

This removes the need for intermediate files.

Fixes Swatinem#31
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

Successfully merging a pull request may close this issue.

2 participants