Support configurable targets

[chriskrycho]

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]

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

[sandersn]

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

[chriskrycho]

Excellent! Thank you for the update!