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

[Packager] Support for jsx filenames in React Native #2303

Closed
pickhardt opened this Issue Aug 11, 2015 · 20 comments

Comments

Projects
None yet
@pickhardt

pickhardt commented Aug 11, 2015

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.

@llanox

This comment has been minimized.

Show comment
Hide comment
@llanox

llanox Aug 11, 2015

Which editor are you using? It works for us when we use, Component.jsx.js on WebStorm. So, WebStorm suggest the right syntax highlighter.

llanox commented Aug 11, 2015

Which editor are you using? It works for us when we use, Component.jsx.js on WebStorm. So, WebStorm suggest the right syntax highlighter.

@negativetwelve

This comment has been minimized.

Show comment
Hide comment
@negativetwelve

negativetwelve Aug 11, 2015

Contributor

This is correct, the react native packager only searches for files with a .js or .json extension (See here and here). I'm using a babel syntax highlighter for sublime and it works with JSX syntax in .js files just fine.

Contributor

negativetwelve commented Aug 11, 2015

This is correct, the react native packager only searches for files with a .js or .json extension (See here and here). I'm using a babel syntax highlighter for sublime and it works with JSX syntax in .js files just fine.

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide Aug 11, 2015

Collaborator

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.

Collaborator

ide commented Aug 11, 2015

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.

@jaygarcia

This comment has been minimized.

Show comment
Hide comment
@jaygarcia

jaygarcia Aug 11, 2015

Contributor

I actually prefer the extension to be .jsx :-/

Contributor

jaygarcia commented Aug 11, 2015

I actually prefer the extension to be .jsx :-/

@pickhardt

This comment has been minimized.

Show comment
Hide comment
@pickhardt

pickhardt Aug 11, 2015

Alright, I'll make a PR for it later tonight.

pickhardt commented Aug 11, 2015

Alright, I'll make a PR for it later tonight.

@pickhardt

This comment has been minimized.

Show comment
Hide comment
@pickhardt

pickhardt Aug 12, 2015

I decided to just do it now: #2305

pickhardt commented Aug 12, 2015

I decided to just do it now: #2305

@brentvatne brentvatne changed the title from Support for jsx filenames in React Native to [Packager] Support for jsx filenames in React Native Sep 14, 2015

@Emilios1995

This comment has been minimized.

Show comment
Hide comment
@Emilios1995

Emilios1995 Dec 3, 2015

Contributor

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).

Contributor

Emilios1995 commented Dec 3, 2015

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).

ghost pushed a commit that referenced this issue Jan 12, 2016

Enable JSX files extension
Summary:
JSX extension is much used in React, this would be a natural addition for React Native.
See: #2303
Closes #5233

Reviewed By: svcscm

Differential Revision: D2818888

Pulled By: mkonicek

fb-gh-sync-id: 856d1b8ba9ff88ba08a00923174e3284f359d774
@kdemoya

This comment has been minimized.

Show comment
Hide comment
@kdemoya

kdemoya Jan 13, 2016

Contributor

@brentvatne @ide This can be closed now.

Contributor

kdemoya commented Jan 13, 2016

@brentvatne @ide This can be closed now.

@pickhardt pickhardt closed this Jan 13, 2016

christopherdro added a commit to wildlifela/react-native that referenced this issue Jan 20, 2016

Enable JSX files extension
Summary:
JSX extension is much used in React, this would be a natural addition for React Native.
See: facebook#2303
Closes facebook#5233

Reviewed By: svcscm

Differential Revision: D2818888

Pulled By: mkonicek

fb-gh-sync-id: 856d1b8ba9ff88ba08a00923174e3284f359d774
@shprink

This comment has been minimized.

Show comment
Hide comment
@shprink

shprink Mar 9, 2016

Hi,

Is this included in any stable release?

shprink commented Mar 9, 2016

Hi,

Is this included in any stable release?

@kdemoya

This comment has been minimized.

Show comment
Hide comment
@kdemoya

kdemoya Mar 21, 2016

Contributor

Hi @shprink, .jsx will not be included in React Native, see #5233 (comment) for reasons.

Contributor

kdemoya commented Mar 21, 2016

Hi @shprink, .jsx will not be included in React Native, see #5233 (comment) for reasons.

@shprink

This comment has been minimized.

Show comment
Hide comment
@shprink

shprink Mar 21, 2016

Dammit! Any way to format jsx with .js extensions on Atom?

shprink commented Mar 21, 2016

Dammit! Any way to format jsx with .js extensions on Atom?

@aymericbouzy

This comment has been minimized.

Show comment
Hide comment
@aymericbouzy

aymericbouzy Jun 9, 2016

at the moment I have the same problem @shprink. I'm manually setting the extension with ctrl + shift + L

aymericbouzy commented Jun 9, 2016

at the moment I have the same problem @shprink. I'm manually setting the extension with ctrl + shift + L

@wayofthefuture

This comment has been minimized.

Show comment
Hide comment
@wayofthefuture

wayofthefuture Sep 13, 2016

yup I'm stuck..... on webstorm same problem

wayofthefuture commented Sep 13, 2016

yup I'm stuck..... on webstorm same problem

@szunigav

This comment has been minimized.

Show comment
Hide comment
@szunigav

szunigav Sep 19, 2016

In webstorm, It works associating the .js extension as JS harmony file type.

screen shot 2016-09-18 at 23 56 05

szunigav commented Sep 19, 2016

In webstorm, It works associating the .js extension as JS harmony file type.

screen shot 2016-09-18 at 23 56 05

NoelLH added a commit to webful-ltd/searchtime that referenced this issue Dec 28, 2016

cpojer pushed a commit to facebook/metro that referenced this issue Jan 26, 2017

Enable JSX files extension
Summary:
JSX extension is much used in React, this would be a natural addition for React Native.
See: facebook/react-native#2303
Closes facebook/react-native#5233

Reviewed By: svcscm

Differential Revision: D2818888

Pulled By: mkonicek

fb-gh-sync-id: 856d1b8ba9ff88ba08a00923174e3284f359d774
@MindFreeze

This comment has been minimized.

Show comment
Hide comment
@MindFreeze

MindFreeze Jun 14, 2017

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.

MindFreeze commented Jun 14, 2017

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.

@cammanderson

This comment has been minimized.

Show comment
Hide comment
@cammanderson

cammanderson Jun 16, 2017

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.

cammanderson commented Jun 16, 2017

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.

@siirila

This comment has been minimized.

Show comment
Hide comment
@siirila

siirila Jan 2, 2018

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.

siirila commented Jan 2, 2018

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.

@yordis

This comment has been minimized.

Show comment
Hide comment
@yordis

yordis Jan 24, 2018

@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)

yordis commented Jan 24, 2018

@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)

@atony2099

This comment has been minimized.

Show comment
Hide comment
@atony2099

atony2099 Feb 16, 2018

thanks , i think 'jsx' will not supported forever

atony2099 commented Feb 16, 2018

thanks , i think 'jsx' will not supported forever

@bensampaio

This comment has been minimized.

Show comment
Hide comment
@bensampaio

bensampaio Mar 19, 2018

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?

bensampaio commented Mar 19, 2018

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?

@facebook facebook locked as resolved and limited conversation to collaborators Jul 22, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.