Avoid errors when replacing Ember modules imports that are used as both a type and a value

[fivetanley]

#109 introduced a safer way to rewrite variable names by generating MemberExpressions to fix code for IE9, but this introduced a regression for packages using @babel/plugin-transform-typescript, such as Ember Data. After 109, Babel would throw the following error if babel-plugin-ember-modules-api-polyfill attempted to rewrite a type information node (in this case, TSQualifiedName), if the file also used the import in runtime JS code.

The code that triggers this looks like:

import { default as RSVP, Promise } from 'rsvp';
// value must be used to trigger this
RSVP.Promise.resolve().then(() => {});
// AND the same import local name must be used as a type as well
function scheduleSave(identifier: RecordIdentifier, options: any = {}): RSVP.Promise<null | SingleResourceDocument> {
}

Error looked like:

Build Error (broccoli-persistent-filter:Babel > [Babel: @ember-data/store]) in -private/system/fetch-manager.ts
-private/system/fetch-manager.ts: Property left of TSQualifiedName expected node to be of a type ["TSEntityName"]
but instead got "MemberExpression"

This was being triggered when ember-data was compiled. Examples were taken from Ember Data's codebase:

• https://github.com/emberjs/data/blob/70b0c55e1a950bed1da64d0ecb4eaa0d5df92f9f/packages/store/addon/-private/system/fetch-manager.ts#L124
• https://github.com/emberjs/data/blob/70b0c55e1a950bed1da64d0ecb4eaa0d5df92f9f/packages/store/addon/-private/system/fetch-manager.ts#L124
• https://github.com/emberjs/data/blob/70b0c55e1a950bed1da64d0ecb4eaa0d5df92f9f/packages/store/addon/-private/system/fetch-manager.ts#L77

This change looks at the type of the referencePath's parentPath to determine whether or not to rewrite the node. Babel does not seem to have a way to get a list of all typescript types, but does seem to prepend the type names with TS. Since type information is removed from Babel output, and babel does not do any linting/type checking of transformed Typescript, it seems fine to leave these nodes alone.

[rwjblue]

This is definitely the right direction, but I do not believe this is the full extent of the fix. While this fixes the error in ember-data, I’m seeing errors in other projects that use TypeScript for types other than TSQualifiedName.

I think we need to detect any type specific node and skip, not just TSQualifiedName.

[rwjblue]

Another common one I’ve seen is TSDeclareFunction.

emberjs/ember.js#18995

[fivetanley]

I had wondered about this as well! I updated the PR to check if the type starts with TS since it looks like all typescript types are prefixed with TS. This doesn't feel great but I don't see a way to get a list of all the typescript types dynamically, and doing something like the starts with TS check should be a guard against any AST types that babel/typescript adds in the future. What do you think about that approach?

[rwjblue]

Ya, seems good to me, though I agree that it does seem a bit unfortunate that there isn't something better.

[rwjblue]

@fivetanley - I just pushed two small tweaks:

• A test that failed in the same way that @glimmer/component was failing
• Tweak the isTypescriptNode guard to only check for things that start with TS

[fivetanley]

Ah, thanks. I thought I had done that, but it's early, time for coffeeeeeeee. Thanks for fixing + merging!

[rwjblue]

https://github.com/babel/ember-cli-babel/releases/tag/v7.20.2 is out with this fix as a minimum dep version.