-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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 macro with ts #2427
Fix macro with ts #2427
Conversation
Bumping this, as it's preventing us from upgrading to the latest version of react-scripts (it bumps the version of babel-macro, which surfaced this issue). Happy to do whatever is needed to land this. Thanks! |
I don't really get how it relates to TypeScript. Does it? |
@Igorbek The test is the best explanation: import styled, { DefaultTheme } from '../../macro' This will throw a |
The issue linked above (#2378) has more context, if that helps. |
@mAAdhaTTah Have you tried importing IMO it doesn't really makes sense to import a type from a macro (maybe @kentcdodds has more insights on this?). |
@lucleray I discussed with @kentcdodds on the babel-macro repo; his thought was you should actually whitelist the TS types. I figure that's probably a step too far, since you don't maintain the TS types, so I just removed the validation.
This would work, but then requires a separate import for SC imports vs types. Also means I can't add a lint rule that says "only import from It's minor overhead, but for what benefit? The macro doesn't need the imports to be valid in order to do its thing, so I'm not sure why we should keep it and push that off to the consumers. |
@mAAdhaTTah You don't want your application to break if the order in which typescript and babel-macros are run in CRA change and the best way to do that is to import the types from If you start importing the types from the macro and typescript is run before babel-macro, you'll get an error. IMO it still makes sense to show an error here, because it's not completely equivalent to import from the macro and from sc. |
This is only true with the check in place.
Why not? Validating whether the imports are valid doesn't seem like the responsibility of the babel plugin so much as the bundler (whether that's webpack/rollup/etc. or the browser), and given that the types for the macro are re-exports of the root types, they should be entirely equivalent, except for the fact that the macro throws when encountering type imports. Without the check, the macro works fine, so the validation doesn't help avoid issues with the macro being unable to run over a file, so I'm not sure what value it's providing besides requiring me to split my type imports from my macro imports. |
Sorry to be a pain, but bumping this again. I think I'd like to suggest thinking about it from this perspective: Setting aside TypeScript at all here, what benefit does validating the imports in the macro provide to either the consumers or maintainers of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. After reading @mAAdhaTTah's comments, I think it won't break anything to merge this and it might make things easier for some people.
Thanks @mAAdhaTTah for your patience 🙏
@probablyup Last poke, I swear, but we've got 2 approvals, can we get this merged & released? Thanks! |
@mAAdhaTTah yup just need you to add a changelog entry |
f302f58
to
cd1e021
Compare
@probablyup Done! |
Check that the imports are split up normally.
cd1e021
to
a53b839
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Could you possibly make a second PR against canary when you get a chance? |
Fixes #2378. That issue will mistakenly closed, as the issue lives in the macro, not in the types. I figured providing a solution would help clarify the issue.
I also added a test for multiple imports, as I didn't expect to see them split in the test I wrote, so I wanted to confirm and test that behavior before I added my change.