.jsx or .js

[nickbalestra]

Airbnb enforce the use of .jsx extension for react specific files where jsx syntax is being used.

There are different opinions on the subject (I suggest reading this thread on the topic). On the same issue Dan Abramov offers reasoning why he prefers .js instead of .jsx.

Would love to hear your feedback on this topic.

[chriscartlidge]

I'd prefer and use .jsx it is a clear indication that jsx syntax are being used and the more specific we can be the better. The JSX syntax are not pure Javascript and therefore shouldn't be indicated they are by being in a .js file.

A lot of IDEs now support the JSX file extension for syntax highlight (this was an issue before).

[munkychop]

A lot of IDEs now support the JSX file extension for syntax highlight

@chriscartlidge most SublimeText users will also have the Babel sublime package for JS and JSX syntax highlighting, which highlights JSX even when contained within files with .js extensions.

Personally, I think that if we architect a clear directory/file structure then it doesn't matter which extension we use, although I'd rather use one consistently for all files – since the contents of the files will change often – and in this case it makes more sense to use .js

[chriscartlidge]

@munkychop I agree with having a clear directory file structure alleviates the issue.

which highlights JSX even when contained within files with .js extensions.

Not every IDE supports this from what I recall.

JSX syntax for me are far removed from what standard JS is and i'd rather that be indicated with the extension.

That's my personal preference :)

[mdboop]

@chriscartlidge what about other future-JS features that babel can transpile, but which are still far removed from standard JS? You can't indicate those through the file extension, and they may be much less obvious than jsx when scanning a file.

[chriscartlidge]

@mdboop Sorry, I should have been a little bit more specific. JSX for me is presentational markup and therefore it should be indicated that it is different from standard JS via the JSX file extension.

[mdboop]

Makes sense. Personally, I'd keep them all as .js since I don't think much is gained from .jsx extensions. That being said, I think we'd be fine either way.

[jknight12882]

I do not think we should be tagging JSX files with the .jsx extension. A few reasons for this:

1. Refactoring - if you add/remove JSX from a file that either had/didn't have JSX, you also need to then rename the file. Which leads to the next reason
2. require - currently, if you have a .js or a .json extension, you can leave that off when using require. In addition, if you have a folder with an index.js, you can do a require on the folder and it'll do the right thing. With the .jsx extension, you have to explicitly add the extension in the require. This becomes nontrivial if you have a component that is a single file that then becomes a folder with an index.js in it. You then have to go through every single instance of that require and delete the .jsx

[nickbalestra]

I'm also for using .js over .jsx.

• Conceptually, I agree with @mdboop: If we use .jsx for files that are not valid js then we should also ask ourself why we don't apply the same rule to .es6, .es7, .stage1,...u name it. JS is a moving target and imho keeping just .js is the simplest solution to avoid tagging via file extension that moving target. In that direction our eslint rules tells more about .OTIdeaOfJSAtThisMomentInTime then any other extension could say. (Well actually that idea of js at this moment of time is pretty much the same as airbnb one, but i think we should spend more effort and time in evolving our idea more then in tagging and handling filextensions to describe it.)
• Practically, if we think that jsx adoptions mainly come to using jsx within react, I would rather stick to what react do (code speak by itself). In that direction @jknight12882 reasoning make sense, and don't forget that you'll have to also configure your transipilation system accodingly (i.e making webpack loader handle .jsx?). Also the babel react-preset handle jsx syntax already so I don't see a point in having somethign different if the transipiling pipeline still the same.

[chriscartlidge]

why we don't apply the same rule to .es6, .es7, .stage1

I can see your train of thought @nickbalestra but for me JSX is a special case because its defining presentational markup.

Stuff like async await, generators & the spread operator are language concepts that are already or soon to be included in an ECMAScript standard.

From my understand JSX syntax isn't going to be apart of the ECMAScript standard for the foreseeable future, but I'm happy to be proven wrong.

However, even if it was apart of the standard because it is presentational it is better of having a separate file extension to signify this.

I'm happy to go with the collective FYI. Just putting my point across :)

[nickbalestra]

@chriscartlidge I see that and thanks for contributing to the conversation! I am just not sure I will make a differente case only because 'its defining a presentational markup', actually jsx is just a JavaScript syntax extension, and in that way jsx is closer to sweetjs then to a markup a language(to bring another example on the table sweetjs files have been also treated with simple .js extension and not with something else as far as i know).

I agree that this doesn't come with an easy answer, but what will dictate the extension beeing used?: The actual target language or an extension of it being used? And what if there will be more extensions being used at the same time?

[felipealfonsog]

It's interesting the topic but at the end of the day, a jsx file just like someone else said before indicates that it's actually React code ... and while Facebook it's not saying anything about it, I'm stick with their rules, and I prefer the old fashion so to say it ---