properly support watch mode when transforming .ts files

[rayzr522]

closes #248

while the diff looks noisy, these changes preserve the codepaths 1:1 while making the actual logic involved much more digestible

the main big change is in resolving modules, where we now resolve both the code as well as the typescript-compiler-specific source & program values. this makes the logic inside of transform() way simpler, where we can just check that resolveModule actually returned something, and if so we know we can pass the code straight along to the inner transform plugin

I also did my best to remove a lot of mutability in variables as it was making it hard to follow the logic, as well as make the types a little stricter/more explicit

if this PR is too heavy-handed, I am happy to restore some of the original structure (e.x. re-inlining getModule so we don't need to pass around a context object) while preserving the main core changes that enabled better watch mode support. however, as you mentioned in #248 that this repo is mostly in maintenance mode, I am hoping that these changes will be welcome as I feel they greatly improve the readability & robustness of the code :3

all tests pass :)

[Swatinem]

Nice, this looks very good!

[Swatinem]

I released this as 5.2.0 as well.

Interesting that dogfooding this for the plugins own type definitions, the changes to use satisfies Plugin rather than plugin: PluginImpl<...> means that it will now inline the whole definition of the output type, instead of using a oneliner for the plugins type definition.

TBH this is the first time I saw satisfies in action (like I said, I’m not doing active TS development for years), but it looks like using an explicit type declaration was better than having the return type inferred.

[rayzr522]

the changes to use satisfies were mainly so that we know the exact hooks/functions in each plugin, eliminating the need to handle the nullability of the transform plugin's hooks since typescript now knew that the functions we required were 100% present

I'm all for exposing the main plugin with an explicit typedef if you don't want to have the public side of things to have those inferred typings, but at least for the inner transform plugin, it was hugely helpful to be able to have more explicit typings that mirrored the actual code

tysm for getting this released!