v4

[danielpza]

Highlights:

This is maintenance release for the most part. No new feature or import resolution changes.

• dropped some features and support for old versions to make maintenance easier.
• updated code to be up date with latest standards.

Migration docs

---

• dropped support for old node versions
• dropped support for old typescript versions
• dropped main/types top level properties in package.json in favor of exports
• dropped jest in favor of node test runner
• esm only

Wishlist (some of these might get released in the current version):

• Clean up tests. The current test process is a mess, needs constant install/rebuild on every change. Look into migrating from jest to vitest/node test runner
• Remove external plugins integrations (nx plugin, etc) to keep surface area small and make maintenance easier, bring nx plugin back, the entry point is small enough to keep and it seems most folks using this plugin are because of nx Why and how are you using this project? #438
• ESM only
• add support for latest typescript version (5.9.2) can be done post v4

---

TODO

• why were the nx plugin and custom ts-node register entry-points needed?, it seems both ts-node and nx have support for typescript plugins. Maybe we need to adjust the top level plugin factory. Related see Discussion: Consider adding support for nx transform style plugins nonara/ts-patch#183
• publish beta version to allow more testing before final release

closes #145

[danielpza]

Just published v4 beta version

you can install it by running

npm install --save-dev typescript-transform-paths@beta

ping @lppedd @nonara @denis-sokolov @blimmer @anthony-y-zhu14 @spdaley in case you want to try the beta before marking it as stable.

I'll leave it in beta for a while to get some feedback. Otherwise I'll publish the v4 version after a while if everything looks good.

---

Link to Discussion

[lppedd]

Thanks, I'll give the Nx plugin a go tomorrow.

[nonara]

Hey @danielpza. Looks pretty good here. Nice work!

The only major thing I would suggest is to not drop the TS "harmony factory".

I definitely agree that doing a new major now gives us the opportunity to drop the older TS versions. Overall, periodic pruning on major releases is a good strategy and is necessary IMO.

With that said, given historical patterns, we will likely find ourselves facing semi-frequent changes to TS compiler API, even on non-major versions, as they don't follow semver (albeit for good reasons).

As I recall, we also had to do some special work in replicating some internal TS API functionality due to elision, which meant even non-public API changes could cause breaking changes. (Although, if memory serves, Ron Buckton may have tightened that a bit so that may be no longer necessary)

In any case, the harmony factory is fairly easy to maintain and allows us to easily add new branches rather than have to release a new major version whenever TS API changes.

Happy to discuss more or provide more context if you'd like.

Other than that, everything looks good! 🎉

[danielpza]

I definitely agree that doing a new major now gives us the opportunity to drop the older TS versions. Overall, periodic pruning on major releases is a good strategy and is necessary IMO.

yes. We need to consider doing this more often, perhaps even during minor releases as well, and just keep a compatibility table updated.

The only major thing I would suggest is to not drop the TS "harmony factory".
[...] given historical patterns, we will likely find ourselves facing semi-frequent changes to TS compiler API, even on non-major versions, as they don't follow semver (albeit for good reasons).

I'm not fully against the harmony factory, personally I don't have a reason to add it back at this point, but I won't be against it if we need it.

[nonara]

@danielpza For clarity, if we don't, we will have to have to do a new major version every time the TS compiler API changes (or sometimes non-public internals), and we would need to drop support for all prior TS versions each time.

Often this is even from a minor update, where a single parameter is added to one of the functions.

Pre-harmony factory, this was tedious. Once it was perfected, it was trivial to handle routing these differences and it was very simple to split for new changes.