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

Import raw JSX from npm package #5274

Closed
igrek8 opened this issue Oct 3, 2018 · 1 comment
Closed

Import raw JSX from npm package #5274

igrek8 opened this issue Oct 3, 2018 · 1 comment

Comments

@igrek8
Copy link

igrek8 commented Oct 3, 2018

Is there a way to import jsx files which will be compiled at the build time too?

I thought CRA 2.0 would support importing non ES5 + babel... any clarifications?

Reproduce:

git clone https://github.com/crabicode/repo1
git clone https://github.com/crabicode/repo2
npm i --prefix ./repo1 && npm start --prefix ./repo1 

Error:

./node_modules/repo2/src/MyComponent.jsx 4:2
Module parse failed: Unexpected token (4:2)
You may need an appropriate loader to handle this file type.
| 
| const MyComponent = () => (
>   <div>
|     MyComponent
|   </div>
@igrek8 igrek8 changed the title Import rawJSX from npm package Import raw JSX from npm package Oct 3, 2018
@Timer
Copy link
Contributor

Timer commented Oct 3, 2018

Create React App v2 supports importing modern JavaScript from an npm package.

JSX is a non-standard syntax feature, and thus should be compiled away before being published.

Please see the comment here: #5103 (comment)

We only compile valid JavaScript syntax in node_modules. JSX is not valid JavaScript. You are using JSX there.

The reason we've taken this stance is because compiling non-standard syntax tightly couples libraries to build tools. For example, if JSX changes and Babel 8 comes out with those changes, suddenly all libraries using JSX internally wouldn't work anymore. You can fix your code but fixing dependencies takes a lot more coordinated effort. And people using Babel 7 (in this example) wouldn't appreciate their code breaking either. So every library would be forced to release a new major version, and possibly maintain both for a long time.

It's also hard to draw a line once you allow experimental things. Most people will want to use not just JSX, but also experimental transforms like class properties. Or decorators. Now we have to argue with every library maintainer about which transforms we want to support, and which we don't. But all of these transforms tend to change until standardized. It already happened many times, e.g. Babel 7 changed the semantics of class properties a little bit. It will happen again.

So say Babel 8 comes out with different class properties behavior. Now you have to vet all libraries you depend on to check if they expect old or new behavior. Nobody can upgrade to the next CRA/Babel because they're locked into the experimental syntax their dependencies (including transitive ones) assume. You can see how this exact situation played out with Babel 7 upgrade in the React Native community. It caused months of pain for RN users, and it's still an ongoing problem.

This is why we don't compile non-standard syntax in node_modules.

@Timer Timer closed this as completed Oct 3, 2018
@lock lock bot locked and limited conversation to collaborators Jan 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants