typescript v4 support

[vladimiry]

[email protected]
[email protected]

typescript-transform-paths/lib/index.js:106
            return updaterFn(typescript_1.default.createLiteral(p));
                   ^
TypeError: typescript_1.default.updateNode is not a function

[nonara]

Thanks for the report, @vladimiry

@danielpza - This is due to the fact that updateNode was an internal function. TS 4 did a total overhaul of the node factory API. Cool, but it's going to be a headache for me in a lot of areas.

If you get a chance to have a look at this (before I can), I'd like to see what happens if we drop the workaround and try it using the normal methods. (updateImportDeclaration, etc) It's possible that we don't need the workaround anymore, since they gutted and rebuilt the internal methods. We're looking to see if it still erroneously adds type-only exports in compiled source after we do an update on import or export declaration nodes.

This bug report was filed, but the OP closed it due to finding the workaround - which now no longer works. If we're lucky, this won't be a problem with the new factory system. If it is still a problem, I'll file a new bug report with TS and probably just bite the bullet and do a PR for TS that fixes it so we can publish a fix for TS 4.

[vwpo]

[email protected]
[email protected]

Confirm that plugin doesn't replace paths in declaration files but it works with [email protected]

[nonara]

Sorry that this took awhile to get to. I've been completely swamped.

The good news is, the upgrade for TS4 compatibility is done and was painless.
The bad news is, the bug in the compiler is still not fixed. 😞

This means that type specifiers in and import or export declaration get output in the JS, which is not good.

I'm investigating it now to see if I can determine what's happening. Stay tuned...

[nonara]

Fixed. New version incoming: #69

Background

For those interested, I didn't track out exactly what was happening in the compiler. I found a few flags discrepancies on the AST nodes (between transformed and original), however, accounting for them didn't make a difference. There may be an internal map somewhere linking some information to the pre-transformed node that is getting lost after transformation.

The MS team would have more knowledge on that area of the codebase than I do, and I don't have the time to dig further into it; however, I was able to find another method to update the node without causing any issues.

In addition to the fix, I've updated the transformer code to prefer the new NodeFactory property of TransformationContext, when it is available. This will keeps us in compliance with TS4+ as the old methods become deprecated over the next few minor TS releases.

TS Issue

I've also opened a new issue for the compiler, which can be tracked here: microsoft/TypeScript#40603

[vladimiry]

Can confirm issue resolving on my case. Thanks everyone involved.

[danielpza]

Big thanks to @nonara for putting up the PR 🎉.

@all-contributors add @vladimiry @vwpo for bug

[allcontributors]

@danielpza

I've put up a pull request to add @vladimiry! 🎉

[danielpza]

@all-contributors also add @vwpo for bug smh

[allcontributors]

@danielpza

I've put up a pull request to add @vwpo! 🎉