8000 Enable JSX files extension by kdemoya · Pull Request #5233 · facebook/react-native · GitHub
[go: up one dir, main page]

Skip to content

Enable JSX files extension #5233

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

Closed
wants to merge 1 commit into from
Closed

Enable JSX files extension #5233

wants to merge 1 commit into from

Conversation

kdemoya
Copy link
Contributor
@kdemoya kdemoya commented Jan 10, 2016

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

@facebook-github-bot
Copy link
Contributor

By analyzing the blame information on this pull request, we identified @cpojer, @amasad and @martinbigio to be potential reviewers.

@facebook-github-bot
Copy link
Contributor

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

@facebook-github-bot
Copy link
Contributor

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jan 10, 2016
@ide
Copy link
Contributor
ide commented Jan 10, 2016

@facebook-github-bot shipit

@facebook-github-bot
Copy link
Contributor

Thanks for importing. If you are an FB employee go to https://our.intern.facebook.com/intern/opensource/github/pull_request/1938800466345905/int_phab to review.

@kdemoya
Copy link
Contributor Author
kdemoya commented Jan 11, 2016

@skevy Is there anything I have to do about the Import Failed tag?

@skevy
Copy link
Contributor
skevy commented Jan 11, 2016

@kdemoya nope.

@mkonicek any idea what happened here?

@martinbigio
Copy link
Contributor

An intermittent unrelated error didn't allow the commit to land. I've just restarted the process. Should land soon :)

@mkonicek
Copy link
Contributor

I see a "naming collision detected", looks unrelated. Merging again. We should implement retries to get around this problem where some internal tests are temporarily broken.

@ghost ghost closed this in 8887492 Jan 12, 2016
@martinbigio
Copy link
Contributor

@mkonicek it would be interesting looking at a dashboard to see why most of the pull requests fail to land. The bot already adds a special label to the issues. Besides this week due to the stability issues we had, I bet that most of the problems are because the pr needs to be rebased. It would be great that if that happens we could comment on the github issue advising the pr owner to rebase :)

@@ -336,6 +336,8 @@ class ResolutionRequest {
file = potentialModulePath + '.native.js';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Sorry to chime in super late but I actually think that this is harmful to support .jsx extension. 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. Supporting more extensions is only going to fragment tools even more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Let's revert unless there's a stronger reason to keep this diff.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revert here: #5296

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As much as I'd love to see .jsx files here you have a good point on supporting other extensions and the fragmentation it could lead too, I didn't see it that way. Thanks @vjeux

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another late late chime in: An argument for supporting .jsx is that up until recently (e.g. pre-flow), .js pretty consistently meant "a version of ES that either matches current or future ES specs". I'm assuming that JSX will never become part of ES proper?

Similarly, why not .flow? There is .ts after all. (aside from it being potentially too late to bring up)

File extensions help tools and infrastructure determine what to do w/ the source. Having to guess is error prone and added complication

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vjeux The specification / EPS for the ES6 module changes: https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! There's so much drama around this subject that we're probably going to wait until it settles and gets shipped in node before taking any action on react native

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same is true for Jest and I'd say Facebook in general. Let's see how this goes for node and then learn from whatever they do :)

Copy link
@yordis yordis Jan 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vjeux your first comment makes sense if you wouldn't talk about React ecosystem. I am having a hard time trying to understand why would you use that argument.

.jsx was invented by React team from the beginning of the time where React appear on the market as long as I remember from 2014 (4 years ago).

So yeah, I wouldn't support any random extension that appear but this one do not makes sense at all, React Native is about React, so probably .jsx would be more important than .js itself, but because we started using Babel we forget where we come from.

Outside that airbnb code style requires it for a really good reason, you are explicit about which file requires JSX syntax and which one doesn't and IDE/Editors likes that extension.

SeemsGood

I can't understand your point.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

christopherdro pushed a commit to wildlifela/react-native that referenced this pull request Jan 20, 2016
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
ghost pushed a commit that referenced this pull request Jan 25, 2016
Summary:
This reverts commit 8887492.

The original commit didn't handle cases like .(ios|android|native).js, and vjeux is in favor of standardizing on .js instead of custom extensions like .jsx or .es6 everywhere.

> 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?
>
> Sorry to chime in super late but I actually think that this is harmful to support .jsx extension. 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. Supporting more extensions is only going to fragment tools even more.

#5233 (comment)
Closes #5296

Reviewed By: svcscm

Differential Revision: D2830784

Pulled By: bestander

fb-gh-sync-id: 9a7a4745803acbcbc5dba176b971c629c904bacd
doostin pushed a commit to doostin/react-native that referenced this pull request Feb 1, 2016
Summary:
This reverts commit 8887492.

The original commit didn't handle cases like .(ios|android|native).js, and vjeux is in favor of standardizing on .js instead of custom extensions like .jsx or .es6 everywhere.

> 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?
>
> Sorry to chime in super late but I actually think that this is harmful to support .jsx extension. 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. Supporting more extensions is only going to fragment tools even more.

facebook#5233 (comment)
Closes facebook#5296

Reviewed By: svcscm

Differential Revision: D2830784

Pulled By: bestander

fb-gh-sync-id: 9a7a4745803acbcbc5dba176b971c629c904bacd
@skevy skevy mentioned this pull request Mar 24, 2016
cpojer pushed a commit to facebook/metro that referenced this pull request Jan 26, 2017
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
cpojer pushed a commit to facebook/metro that referenced this pull request Jan 26, 2017
Summary:
This reverts commit 888749220dac26382412f2c38ac5f9205cc842e5.

The original commit didn't handle cases like .(ios|android|native).js, and vjeux is in favor of standardizing on .js instead of custom extensions like .jsx or .es6 everywhere.

> 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?
>
> Sorry to chime in super late but I actually think that this is harmful to support .jsx extension. 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. Supporting more extensions is only going to fragment tools even more.

facebook/react-native#5233 (comment)
Closes facebook/react-native#5296

Reviewed By: svcscm

Differential Revision: D2830784

Pulled By: bestander

fb-gh-sync-id: 9a7a4745803acbcbc5dba176b971c629c904bacd
@RalfN
Copy link
RalfN commented Mar 13, 2018

Im puzzled by this. Why would you want to call a file .js when it is not a proper javascript file and break all other tooling? The question isn't wether .jsx files should be supported, the obvious and in your face bug is that supporting .js files as if they are .jsx files is breaking the standard, makes tool integration harder and is generally considered to be 'HARMFULL BEHAVIOR' just like renaming a .json file to an .xml file would be. It is self centered. We may want to use tooling (linting, beautifiers) that expects the file extensions to follow the proper conventions. As nice or imporant as this project may be, it is not important enough to warrent the arrogance of diluting a standard filetype association.

@jh3141
Copy link
jh3141 commented Mar 14, 2018

Not sure why this has been closed. JSX is a separate language to ES and should not use the same file extension in order to allow external tools (e.g. code formatters, linters, code metric generators, etc) to identify the type and behave appropriately. Not supporting this just because there are edge cases that might require thought is absurd.

@andrenerd
Copy link

temp solution. but we need built-in one!
http://www.fallingcanbedeadly.com/posts/enabling-react-native-jsx-extension

@gabrielmaiaf
Copy link

@savvaoff why don't you make a PR about this solution?

@yordis
Copy link
yordis commented Apr 13, 2018

@gabrielmaiaf because that is not a problem at all. Many of us knows how to fix this but the core contributors will no take the PR fixing the issue 😢

@tjbenton
Copy link
tjbenton commented Apr 17, 2018

Just so everyone one knows it is possible to use JSX files with react native. Inside of the root of your project add a file named rn-cli.config.js and place the following code into it.

// ./rn-cli.config.js
module.exports = {
  /// @name Make ReactNative Great Again
  /// @description Allows you to enable support for JSX files, and `.mjs` files which is the new node standard
  /// @source http://www.fallingcanbedeadly.com/posts/enabling-react-native-jsx-extension
  /// @note One caveat, The `index.js` file in the root of your project has to be `.js`. 
  getSourceExts: () => [ 'jsx', 'mjs', 'js' ],
}

@agentwaj
Copy link

@tjbenton's solution seems to not work in newer versions of RN (I'm on 0.57.7) but as per facebook/metro#248 (comment), this works:

module.exports = {
  resolver: {
    sourceExts: ['js', 'json', 'ts', 'tsx', 'jsx']
  }
};

@LukaGiorgadze
Copy link
LukaGiorgadze commented Jun 19, 2019

In newer version just change metro.config.js

module.exports = {
  transformer: {
    getTransformOptions: async () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: false,
      },
    }),
  },
  resolver: {
    sourceExts: ['jsx', 'js'],
  },
};

@UsamaaAkram
Copy link

module.exports = {
resolver: {
sourceExts: ['js', 'jsx']
}
};

@deepankarsandy
Copy link
deepankarsandy commented Sep 20, 2019

I'm on RN 60.4

rn-cli.config.js

module.exports = { resolver: { sourceExts: ['js', 'jsx'] } };

metro.config.js

module.exports = { transformer: { ... }, resolver: { sourceExts: ['jsx', 'js'], } };

nothing seems to work.. Unable to resolve module

@tjbenton
Copy link
tjbenton commented Oct 10, 2019

Turns out the reason why sourceExts: [ 'jsx', 'js' ] doesn't work is because js has to be defined first. I would also in resolverMainFields: [ 'main' ] because there's several packages that are starting to use the "react-native": "src/index.ts" setting the in package.json which tells the metro parser to use the ts files instead of the "main": "lib/index.js" file. An example of this can be found in the latest version of the react-native-permissions library. Note the resolverMainFields isn't required to fix this problem it just seems to make it run faster.

module.exports = {
  // Allows you to enable support for JSX files, and `.mjs` files which
  // is the new node standard
  // https://github.com/facebook/react-native/pull/5233
  // Note: One caveat, The `index.js` file in the root of your project has to be `.js`.
  resolver: {
    sourceExts: [
      'js', // note this has to be defined first or you get an error
      'json',
      'jsx',
      'mjs',
      // required because the react-native cli ignores `resolverMainFields`
      'ts',
      'tsx',
    ],
  },
  // this prevents the `react-native` field from being used so `ts` and `tsx`
  // files don't have to be transpiled
  // resolverMainFields: [ 'main' ],
  transformer: { ... },
}

Here's a screenshot of this config working for me.

"metro-react-native-babel-preset": "0.56.0",
"react-native": "0.61.2",
"react": "16.9.0",

Screen Shot 2019-10-10 at 9 22 45 AM

If you don't put the 'js' option first you get this error.

TypeError: EventTarget.apply is not a function. (In 'EventTarget.apply(void 0, WEBSOCKET_EVENTS)', 'EventTarget.apply' is undefined)

Screen Shot 2019-10-10 at 9 13 13 AM

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0