A workaround to use latest JS features without ejecting, is this considered bad practice?

Take a look at this command/script:

rm -rf src && babel dev -w -d src --presets=es2015,react,stage-0 --plugins=transform-decorators-legacy --copy-files

We are telling Babel to:

• Initialize an empty src directory, this is the main CRA src we are used to.
• Watch for any changes in all JS files located in the dev directory, and compile accordingly (compiled version of all dev is now located in src).
• We are interested in supporting some presets (es@2015, react, es@next).
• We are interested in having some plugins/additional functionality (decorators).
• Replicate all non JS files in dev, now we have an exact replicated and compiled version of our app in src.

app/
-- dev/ .. where all development happens, extended with all the new JS features
-- build/ .. contains final build of the app
-- src/ .. contains compiled JS code generated by Babel

Translating this idea via package.json:

{
  "devDependencies": {
    "babel-cli": "6.24.1",
    "babel-plugin-transform-decorators-legacy": "1.3.4",
    "babel-preset-es2015": "6.24.1",
    "babel-preset-react": "6.24.1",
    "babel-preset-stage-0": "6.24.1"
  },
  "scripts": {
    "build": "react-scripts build",
    "start": "react-scripts start",
    "start:babel": "rm -rf src && babel dev -w -d src --presets=es2015,react,stage-0 --plugins=transform-decorators-legacy --copy-files"
  }
}

When running yarn start in parallel with yarn start:babel, we get the desired result.

Pros

• Use the latest JS features without having to eject. This is not the place to discuss whether we should or shouldn’t, let’s just take it for granted for now that we are interested in using the latest features available.

Cons

• Limited linting and type checking experience with ESLint and Flow, (any additional features added and not supported by react-scripts would typically throw either a warning or an error), we are unable to utilize these tools to their fullest potential.
• Limited debugging experience, I would say it’s almost non existent now because of the extremely verbose compiled code, you get the high level error detection abilities only.
• CRA compiles an already compiled code now? how bad is this?

Would love to hear your thoughts on this.

[sonaye]

Stage 0 was just an example, typically one would go with stage 2 or stage 3 or just cherry pick.

I’ve been developing with a nice set of less-than-stage-3 features for over a year now in React Native, I reached a point where I just cannot truly be productive without utilizing them. Take these two examples which are both at stage 2 at the moment. https://babeljs.io/docs/plugins/transform-decorators/ https://babeljs.io/docs/plugins/transform-class-properties/

e.g. I didn’t have to write .bind(this) for over a year now, and a couple of days ago I found myself googling the different methods to achieve that, there is just no way that I am going back to those ol’ days 😅

It is similar to going back to building web apps with jQuery instead of React, it’s just not the same experience, and that’s just the beginning of a very long list of arguments. Language can be -and is- a true enabler.

I am hoping that maybe someone already went through this and could possibly provide some input on it.

[raymondsze]

@sonaye Just a suggestion.

I created a library called ‘create-react-scripts’, it use the similar manner as what “react-app-rewired” did but you are able to re-publish it like your version of react-scripts which “react-app-rewired” not allow you to do so.

To enable the decorator support, You could make use of “create-react-scripts” and “create-react-scripts-babelrc” to enable the babelrc option of babel-loader, so you can override the babel configuration and you still enjoy all things create-react-app provides.

I am still a newbie on open source community, looking for feedback. https://github.com/raymondsze/create-react-scripts