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 configurable targets #36

Closed
chriskrycho opened this issue Jun 1, 2020 · 3 comments
Closed

Support configurable targets #36

chriskrycho opened this issue Jun 1, 2020 · 3 comments

Comments

@chriskrycho
Copy link

I'm working on an RFC for how we manage Ember's ecosystem-wide SemVer commitments and TS together (🎉) and one of the elements I'm designing in the midst of it is the use of downlevel-dts to handle breaking changes across minor versions of TS. The current approach of supporting 3.4+ is good enough to get the job done (and in my testing so far, I really appreciate downlevel-dts's level of "it just works"!)—but what we'd really like to be able to do is generate a .d.ts file for each TS version in a given package's support matrix, so that given a set of source files, you'd do something like this:

yarn downlevel-dts --to=3.6 . ts3.6
yarn downlevel-dts --to=3.7 . ts3.7
yarn downlevel-dts --to=3.8 . ts3.8

Deciding automatically which need to be built, a la #26, would also be super neat, but having this level of granularity for us would be really helpful. In particular, we'd prefer that making a change to support a new version of TS doesn't entail changing the types published for users who haven't upgraded TS yet.

For example: we'd really prefer that when 3.8 added support for type-only imports and exports, our emit for 3.7 consumers didn't revert from get semantics to readonly semantics.

If there's interest, I'm very happy to do the implementation work. Having read the source, it looks to be neither trivial nor extremely difficult, and it would be extremely valuable for our use case!

@chriskrycho
Copy link
Author

The RFC for Ember addons and type stability I mentioned; see especially comments on use of downlevel-dts.

@sandersn
Copy link
Owner

Fixed by #44; I just published 0.7 that contains this feature.

@chriskrycho
Copy link
Author

Excellent! Thank you for the update!

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

2 participants