"Unexpected token" error if importing jsx

[pmunin]

Is this a bug report?

Yes

Can you also reproduce the problem with npm 4.x?

Yes

Which terms did you search for in User Guide?

I search for different combinations of keywords describing using react-scripts-ts for app with both tsx and jsx modules

Environment

1. npm ls react-scripts-ts (if you haven’t ejected): react-scripts-ts@2.6.0
2. node -v: v8.2.1
3. npm -v: 5.3.0
4. yarn --version (if you use Yarn): 0.27.5
   <<<<<<< HEAD
5. npm ls react-scripts (if you haven’t ejected):
   =======
6. npm ls react-scripts-ts (if you haven’t ejected):

Fix Code Review

Then, specify:

1. Operating system: Win7 SP1 x64
2. Browser and version (if relevant): Chrome 60

Steps to Reproduce

I have application with mixed js(x) and ts(x) modules, which I need to coexist and compile properly, however when I rename any of tsx modules to js or jsx, I get the build error:

1. create-react-app my-app
2. rename src/App.tsx => src/App.jsx
3. npm run build

Expected Behavior

Successfully compiled build/dist

Actual Behavior

Actual results:

./src/App.jsx
Module parse failed: c:\temp\test-react-typescript\src\App.jsx Unexpected token (9:6)
You may need an appropriate loader to handle this file type.
|   render() {
|     return (
|       <div className="App">
|         <div className="App-header">
|           <img src={logo} className="App-logo" alt="logo" />

Reproducible Demo

Please just follow steps, it's very easy to reproduce.

[pmunin]

I looked at sources and I see that for some reason, script-ts' webpack.config.ts have no babel loader mentioned at all, which looks like a bug to me. It makes sense for react-scripts-ts to be a superset of react-scripts and include everything what react-scripts includes plus ts-loader.

Workaround I used - is just to use npm run eject and do it manually - it would be great if it can become out of the box

[joshhornby]

I agree with @pmunin I'd love to use this package replace CRA and help migrate to TypeScript, seems a bit extreme to have to eject just to be able to do this.

[wmonk]

Hey, thanks for this report. Currently this is entirely intentional, not a bug. react-scripts-ts is not acting as a superset of react-script at the moment, it is a complete replacement for typescript applications.

The original intention of the project was to be a replacement, which meant that it fell into the category of starting a new project with typescript support, instead of converting existing CRA generated projects - which I think is the same for the original CRA project too (new projects, instead of converting old ones).

There is a PR #74 that would go further to enabling this behaviour. My major concern with adding babel and JS support is that it would open up a whole range of potential new issues and mean support for more tooling, which isn't easy to maintain.

[pmunin]

As an idea for a cheap and flexible fix - add ability to customize/override of webpack.config.js in the project folder, like it works for tsconfig.json. Ideally - expect a function accepting as a parameter preinitialized (default) configuration object, where function returns overridden config, so developer could do something like:

//webpack.config.js (in project folder)
module.exports = function(defaultConfig, env)
{
   defaultConfig.module.rules.push({ 
      test: \/.jsx\/,
      loader:"babel-loader"
   });
   return defaultConfig;
}

This override will work both for devserver and prod build.

PS: I believe it's very low chances to meet a real-world app that's purely typescripts with no js included at all. And if es6 js included, then babel and build customization is needed.

[wmonk]

I'm afraid that is not going to land in this project, adding something like this is deviating far from the original react-scripts project, which is something I definitely don't want to do. I would like to open this up for discussion to see what other users are thinking. If this is a feature many want, then we will support it as the existing react-script package does. My gut feeling is that this will open up a whole host of issues. I also don't believe that it is completely unreasonable to eject and add this behaviour. Once you have completely completed the process of moving to TS then you can utilise this project again.

PS: I believe it's very low chances to meet a real-world app that's purely typescripts with no js included at all. And if es6 js included, then babel and build customization is needed.

I'm not sure this is necessarily true. Possibly for converting existing JS projects to TS. Considering the amount of downloads this package has had, this is the first (I think) issue of this nature.

[pmunin]

I'm not sure this is necessarily true. Possibly for converting existing JS projects to TS. Considering the amount of downloads this package has had, this is the first (I think) issue of this nature.

Hmm, here is the scenario that I believe should be common: User's typescript imports some 3rd party js-module (e.g. that uses es6 or some latest js features). In this case, webpack trying to bundle it into the same js output and eventually app will fail in runtime, because latest js features of 3rd party were not babel-ed out? Am I missing something?

[wmonk]

That shouldn't happen anyway, as generally we don't run babel (or typescript) across 3rd party dependencies. If you definitely want that behaviour you will have to eject.

facebook/create-react-app#1125 this thread from create-react-app also gives the same advice.

[pmunin]

I see your point, however many learning materials about webpack that I saw mentioned bunding vendor libs into dist as something common.

Another problem I'm dealing right now, that makes my point: missing/inconsistent typing. I'm dealing with material-ui package now, where recommended version to use is 1.0.0-beta, when latest Defined typings are v 0.18.0, which causes typescript compilation errors. So for those files where I'm using components with problematic types I could use JSX, but for the rest - I would use typescript.

[joshhornby]

I am currently using react-app-rewired and doing the following:

// config-overrides.js
var paths = require('react-scripts-ts/config/paths');

module.exports = function override(config) {
    config.module.rules.push({
        test: /\.(js|jsx)$/,
        include: paths.appSrc,
        loader: require.resolve('babel-loader'),
        options: {
            babelrc: false,
            presets: [require.resolve('babel-preset-react-app')],
            cacheDirectory: true,
        },
    });

    return config
}

and in package.json "start": "react-app-rewired start --scripts-version react-scripts-ts",

This allows me to migrate my app file by file across to typescript.

[pmunin]

Oh great, this is exactly what I suggested as a cheap fix above. Didn't know there is already existing solution. Thanks!

[wmonk]

Glad this is solved!

[n8sabes]

Thanks @joshhornby @pmunin, this workaround solves the problem.

Just needs to do some tree shaking uglification as the build output is massive when including JSX as-is.

It would be nice to incorporate this as a standard behavior of the react-scrips-ts as jsx is often a requirement at some point within larger projects.

[n8sabes]

@joshhornby do you have any insight into how to reduce the (massive) size of the babel output when including jsx? I assume tree-shaking is occurring with tsx, but not on jsx.