-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
fix ts import issue with fcct #31
Conversation
`@babel/plugin-transform-typescript` removes unused imports because it assumes they're types (yuck). That's how TS behaves so it's at least understandable. However, it doesn't seem to respect the fact that our plugin is *emitting* code that *will* use the imports. This adds a failing test.
Firstly, I really appreciate you trying to fix this problem!!! however, I don't think we want to go down this route -- "two wrongs don't make a right" -- @ef4 is working on fixing the babel typescript plugin. |
@ef4 @NullVoxPopuli i know there is the attempt to fix it in typescript-transform, but think I have a good fix now. pre runs before any visitor, so it works independent of the order. |
The only downside is that it also does not remove unused type imports. |
I agree that we might need to do our own I think we can probably extend the ideas here to be more targeted though. For example:
This would allow all the normal removal of imports to take its usual course, and limit our changes to precisely the names that we know we need that other plugins can't know that we need. |
I was also trying that first. But reinsert might be to late, since amd transform did already run. I thought dev mode doesn't do template analysis? |
Builds off #31 to fix #30. Instead of keeping *everything* as in #31 (which is not safe in general), we use the `pre` to take a snapshot of available imports and then only when we discover that a template wants to use a name that is not in scope do we check if it was in the original set of available imports and reintroduce an import for it.
I continued this branch in #32. |
Builds off #31 to fix #30. Instead of keeping *everything* as in #31 (which is not safe in general), we use the `pre` to take a snapshot of available imports and then only when we discover that a template wants to use a name that is not in scope do we check if it was in the original set of available imports and reintroduce an import for it.
No description provided.