[Packager] Support for jsx filenames in React Native
pickhardt opened this issue · comments
It seems that files with the extension .js can be required, but .jsx files cannot.
The following works fine:
var HelloPage = require("./src/views/screens/hello.js")
But when I rename the file and the code to .jsx, it gives the exception "Requiring unknown module "./src/views/screens/hello.jsx". If you are sure the module is there, try restarting the packager."
Restarting didn't seem to help. Is this a problem with something in React Native?
I want to name the files with JSX so that my editor uses the right syntax highlighter.
Which editor are you using? It works for us when we use, Component.jsx.js on WebStorm. So, WebStorm suggest the right syntax highlighter.
It'd also be reasonable to add it to the list in the watchRootConfigs.
Agreed. If you want to see this happen the best way is to submit a PR.
I actually prefer the extension to be .jsx :-/
Alright, I'll make a PR for it later tonight.
I decided to just do it now: #2305
If you are using Sublime Text 3 with the Babel-Sublime extension, click on the lower-right section, (there you can select the syntax for the file,) and go to Babel -> JavaScript (Babel).
@brentvatne @ide This can be closed now.
Hi,
Is this included in any stable release?
Hi @shprink, .jsx will not be included in React Native, see #5233 (comment) for reasons.
Dammit! Any way to format jsx with .js extensions on Atom?
at the moment I have the same problem @shprink. I'm manually setting the extension with ctrl + shift + L
yup I'm stuck..... on webstorm same problem
In webstorm, It works associating the .js extension as JS harmony file type.
After reading the comments on this issue, my opinion of the react-native team has changed drastically.
The only reason stated for not supporting .jsx is that it would raise a conflict between index.ios.js and index.ios.jsx. Have you heard of priority?
And do you realize that this basically means that ReactNative does not support React and Facebook does not support something invented by Facebook?
I have a native project that uses some code from a react web project and now I have to change file extensions in order accomplish this for no valid reason.
Like it or not, JSX is not vanilla JS and tools/editors/developers need to know what a file contains without parsing the entire content. Otherwise we might as well support only 1 file name as well.
I agree with the above that have a preference order is a good/safer solution. People are working around this issue with various atom/IDE changes, but your expectation as a react developer is the strongest naming convention is JSX is a JS file containing a React Component that is expressed using JSX (putting it out there..).
We are trying to support components in web/iOS/android, and because of this opinion to not support JSX extensions we end up having to drop jsx in our web naming to get a middle ground. This is not nice as suddenly we have an opinionated library forcing our standards. Our standard React and development coding standards are affected (including ESLint standards, such as using airbnb etc). The expectation is .jsx contains JSX, and a .js does not contain JSX.
It could be nice to be able to setup the following assumptions and have IDE/ESLint existing developer adopted standards happy;
- component.jsx (common code between web/ios/andriod if safe)
- component.ios.jsx (specific to ios)
- component.android.jsx (specific to android)
- component.web.jsx (specific to web, outside scope of this project obviously, but achievable for webpack etc)
If developers want to use .js, they still should be able to.
The webpack order priority works fine for developers and is flexible. I am assuming that the Packager has an order priority that is platform specific now (I should check..). Maybe you could have two priorities, that could have a default like: iOS: ['', '.ios.jsx', 'ios.js', '.jsx', '.js'] and then andriod ['', '.andriod.jsx', '.android.js', '.jsx', '.js'] for instance? It would bring uniformity to peoples projects and restore the balance of the universe ;-) It seems like an ideal goal? Even better as a second step to make it configurable, but just getting support in there would be beneficial to start.
I can appreciate there are some challenges and probably ones I haven't presented here, but these are not uncommon challenges that we've had to deal with in developing with React in the first place. I think the citing of the comment about 'what happens when you define a .js and a .jsx' being confusing is valid, but only to a degree. I would have thought we've all had to deal with that as React developers.
The whole React IDE/Ecosystem (ESLint etc) are generally geared towards supporting .jsx has JSX as the convention. Developers have to embrace their decisions around conventions and believe in them, because it does allow us all to work together better, and generally gets annoying if you create rules outside current convention.
If this is going to be the case, could you get something added to the documentation that clarifies that filenames can't be .jsx. I just spent a couple hours trying to figure out why my module couldn't be found only to discover that React Native doesn't support the .jsx extension that is common for React projects. Maybe a section on React Native differences from React would be a good place for this as well as other differences between the two projects.
@MindFreeze @cammanderson I think we lost this battle since @vjeux dictated it will no be included, even when many people in the team let it to be merged, because it made sense.
Unfortunately this pull request doesn't implement with .ios.jsx. But, when/if it does, it raises more questions like what happens if you have both ios.js and ios.jsx?
@vjeux
We can't figure out how to give priority of the files, seriously, that is the argument. Just pick one, our responsibility is to know how that works and pay attention, you do not need to be the Protector of all the programmers. Either jsx first and then js (which would be more natural) or js first and then jsx, it doesn't matter just decide which one. I trust that you will take the right decisions and Babel give you the tooling for that as simple as re-arrange an array.
We now live in a world where we have many transforms for es6, flow, jsx... Why would we add .jsx but not .flow or .es6
@vjeux
Here is the thing, JSX was invented by Facebook for React.
Yes, you are right, today we can even put flow types in Javascript files but you are missing about something really important to keep in mind.
Why would we add .jsx but not .flow or .es6
@vjeux
I can take my flow code and put it somewhere else where there is no React components, I can use it on Angular Vuejs Polymer, Ember and even Nodejs backend code as long as I use the transformation.
Those extensions have nothing to do with specific framework (React). So what is the point of your argument because I am not following.
Also, those extensions were based on Babel and the ecosystem around it, where you are used to use those tools for using the extensions but nobody said that you require to use specific technology because the focus of those extensions is to enhance the Javascript language, no for create some syntactic sugar for specific framework.
JSX was invented strictly for React 4 years ago (Preact now and any other VDOM syntactic sugar)
So again, what is your point?
Supporting more extensions is only going to fragment tools even more.
@vjeux
Support more random extensions, yes, you are right.
But let's forget 4+ years of React development and let's call it now fragmentation of the tools, let's forget that many people have code with .jsx on the web that they could port to the Mobile but for some reason they have to rename the files, I do not see the point.
The reason that code style like AirBnB exists and force engineers to use jsx is because you do not need to scan your project for find out what you could extract out of your project, maybe, because it have nothing to do with React, again maybe, but at least I can see what pieces of my code is actually React based, which probably would means it will no be that easy to just move outside React ecosystem/project.
Outside that,
@MindFreeze your argument is exactly what make me questioning the argument from @vjeux , JSX was invented BY Facebook since the creation of React, it doesn't make sense to use the argument about .jsx.
But again, I think that this is a lost battle, you can give them as many arguments as possible and they will no listen, what other argument could you give when JSX was invented BY Facebook FOR React, like one person is wiping out 4+ years of history because we have Babel now.
I hope I am wrong about it, but time will let us know if React Native project is run by dictator or leaders (the core difference, the first one dictate how things work no matter what and the second listen) I hope at least to get some strong responses because so far is one person vs everyone else (even the core that let the feature to get into the package and then remove, sign)
thanks , i think 'jsx' will not supported forever
This doesn't make any sense... As said before, Facebook invented jsx so why not stick to this decision?
I have a React project with lots of components using the jsx extension. Recently we started experimenting with React Native but we realized that the only way to share code would be renaming every single jsx file to js. Worse than that is that Node.js is introducing the mjs extension. For that reason, we have lots of mjs files because we want to be ready for when Node releases mjs and because we want to be able to share ES modules between the frontend and the backend. However, once again React Native also does not support mjs so the solution is to duplicate mjs files as js files...
The nice thing about having different extensions is that when I look at a file I can deduce the following from its extension:
js: it is a JavaScript script with no imports / exports which can be used across platforms;mjs: it is a JavaScript module in strict mode which can be used across platforms;jsx: it is a JSX module in strict mode which can only be used for the frontend and requires transpilation.
When it comes to mjs, Node already confirmed that this is happening and Babel 7 and Webpack 4 added support to it. So why not React Native? And where is the question about mjs different from the question about jsx?