-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
issue with gts/gjs if ts transform is enabled #611
issue with gts/gjs if ts transform is enabled #611
Comments
I believe I'm getting into this problem. I have a pkg that exports components in the root of the pkg ( This is happening in Worksimport {Button} from '@frontile/buttons';
console.log(Button);
<template>
<Button>Test</Button>
</template> Does not workimport {Button} from '@frontile/buttons';
<template>
<Button>Test</Button>
</template> Versions:
Note 1: |
For apps that are already disambiguating by using I think we should definitely have a way to enable that option, and that would be good enough for my app (but we may also just switch to Embroider soon anyway). But I am not sure we can rely on only that solution (essentially saying |
@chancancode I think we could even go as far as to lint against "incorrect" tsconfig.jsons and babel configs. I think we have a problem of too much config right now, (as a whole JS ecosystem), and there are too many ways to do things incorrectly. Like, absolutely no one should not be using |
I'm looking how we could fix this in babel. But there is no straightforward way... |
Probably the most reliable thing is to restage our pipeline so we resolve the |
well, it could also be any other babel plugin that adds imports dynamically. So I think it needs to be fixed anyway in EAI |
I actually found nowthat there is also |
I think the best "earlier" would mean making content-tag itself pluggable so it can accept a callback that would invoke glimmer's precompile. Then the whole transformation could happen in the content-tag stage and all the downstream tooling would not see the eval form. I think it's doable, but it's not trivial given that this does require implementing Alternatively, we could introduce an extra babel pass. At a minimum this would double the traverse cost, at a maximum it would double the parse cost too. I think a double-parse would be unacceptably expensive, but an additional traverse might be ok. In either case, it's best if the same stage that produces the scope bag is the one that precompiles the template to wire format, because both require parsing the template and it's better not to repeat that work. |
Yeah, the babel plugin ecosystem is kinda a mess when it comes to the mutation APIs. Lots of plugins don't use them at all, some plugins will break if you try to use the methods in your plugin. In babel-import-util we don't use them, but we also manually ensure that babel's scope-aware APIs are updated to see the changes we're introducing. (That being one of the major benefits in theory of using the mutation apis.) |
For example, doing a traverse in pre handler in template compilation plugin? |
Yes, that might work. |
Mmm, but it would break other things, when a babel plugin wants to modify the content of the template/hbs contents |
Since ts babel plugin removes the unused (but used in template) imports at program enter, this plugin doesn't have a chance to analyse them.
This plugin probably needs to do the same as ember babel template compilation.
Or just analyse the imports at program exit
Maybe the approach needs some rethink as every plugin that wants to analyse imports of gts files needs to adop the same behaviour.
The text was updated successfully, but these errors were encountered: