Skip to content
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(react): Fix jsx runtime rewrite #12754

Closed
wants to merge 1 commit into from
Closed

fix(react): Fix jsx runtime rewrite #12754

wants to merge 1 commit into from

Conversation

lforst
Copy link
Member

@lforst lforst commented Jul 4, 2024

I screwed up the matching in the last PR: #12740

@lforst lforst requested a review from andreiborza July 4, 2024 09:44
@alexandersorokin
Copy link

It's look like this MR will break compatibility with react@18. js extension is only need if there are no an exports field in package.json or that field contains js extension.

But react@18 does have exports field without js extension. See: https://www.npmjs.com/package/react?activeTab=code
image

Only react@17 doesn't have exports field.

@lforst
Copy link
Member Author

lforst commented Jul 4, 2024

Right, so we're a bit deadlocked. If we don't have the .js extension we break react 17, if we add the .js extension we break 18. 🤔

@alexandersorokin
Copy link

I am sure that Sentry should support react@18 and react@19 instead of react@17 because it allows users to upgrade to the newest version of react. So the imports should remain extension-less.

Users of react@17 can use an workaround in their bundler config (configuring an alias).

@lforst
Copy link
Member Author

lforst commented Jul 4, 2024

@alexandersorokin yup I am generally with you. I am just wondering whether there is a way we can make it work for everybody. (maybe we'll just switch back to React.createElement and live with the warning).

@alexandersorokin
Copy link

react@19 will drop support of old jsx transform for tsx files (it uses React.createElement internally). But I don't know does it mean that React.createElement should not be used directly anymore.

Nevertheless, there are enough libraries with the same issue. They are not going to make it works for everyone. So esm consumers will likely have to configure their bundler to work with both react/jsx-runtime and react/jsx-runtime.js even if @sentry/react will incorporate a fix.

@lforst lforst closed this Jul 9, 2024
@lforst lforst deleted the lforst-fix-jsx branch December 3, 2024 09:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants