Use project typescript version.
Our project is using [email protected], but latest ts-migrate is using [email protected]. So is there any way to running ts-migrate at typescipt 4.0.x ?
This would be a big help for me. For instance, I'm currently on TS 3.7. Instead of jumping to the latest TS atomically, I'd like to run the tsIgnore plugin separately for each incremental TS release. That way, when my team is removing the expect-errors, we know which TS release introduced the error.
I can see the use case here, though it does present some challenges in maintaining this project. I don't plan to work on this, but I'll jot down some thoughts which may spur further conversation and give an idea of what I think a proposal and implementation would need to address.
Specifying the Dependency
We could ensure that we always use the project's TypeScript version by specifying typescript as a peer dependency rather than a normal dependency, and specifying a range of compatible versions. I think this would work, but a couple things to note:
- I don't believe ts-migrate could work as a globally-installed package (eg with
npm install -goryarn global add). I think this is probably fine, but worth acknowledging. - The usual usability pain of peer dependencies. NPM v7 now installs them by default, at least, which I think helps.
Maintaining Compatibility
Being able to work with a project's TypeScript version means that ts-migrate has to stay compatible with multiple versions of TypeScript. I think we'd need to define:
- A range of TypeScript versions that ts-migrate is compatible with.
- A rough plan for what the future version policies will be. We can't support old TypeScript versions forever.
- A strategy for maintaining compatibility in ts-migrate's code base.
That last point is the trickiest, since TypeScript's APIs can change in incompatible ways between versions. For example, TypeScript 4.0 introduced a new node factory API, which ts-migrate uses. The old API is deprecated and slated to be removed in TypeScript 4.3. In order to stay compatible with versions earlier than 4.0 and later than 4.2, we'd have to maintain our own abstraction around both APIs.