@babel/plugin-proposal-class-properties does not work with CRA 2.0

[jimbojetlag]

Install [email protected] and use a package with classProperties, for example @material/react-top-app-bar, you will get this error:

...
 Support for the experimental syntax 'classProperties' isn't currently enabled
...
Add @babel/plugin-proposal-class-properties (https://git.io/vb4SL) to the 'plugins' section of your Babel config to enable transformation.

[gaearon]

Why would you expect it be enabled for third party libraries?

Publishing code that relies on experimental transforms is quite reckless, assuming somebody does that. It will most definitely break at some point as the spec changes. It’s also unusable in Node.

Or do you mean that this is a false positive?

[jimbojetlag]

I had the impression that this is enabled by default, maybe I'm wrong.

In any case, adding a .babelrc file like this in project root doe snot help:

{
  "presets": [
    "react-app"
  ],
  "plugins": [
    "@babel/plugin-proposal-class-properties"
  ]
}

Is the custom .babelrc supposed to work in CRA 2.0? The documentation for the alpha version is nonexistent and its not easy to compile this information by searching through random issues.

[gaearon]

Sorry, if you’re not ready for all the problems that come with using an undocumented release then I recommend you not rely on it.

No, it’s not expected that custom .babelrc should work. It was not, and is not supported.

Yes, class properties are turned on by default in application code. Because you have full control over it, and if the spec changes, you could run a codemod.

Class properties are intentionally off for library code. Because they are not finalised, and the spec may change or even become abandoned. Supporting this would create a huge ecosystem burden because now people won’t be able to upgrade to future Babel releases without also breaking the libraries that they depend on, and vice versa. They’re also completely unusable in Node and other environments.

If @material publishes code that relies on experimental features like class properties, I suggest filing an issue with them, and asking them to reconsider. This is pretty bad for the ecosystem as a whole, and I hope this was a mistake and not an intentional decision.

[gaearon]

I filed material-components/material-components-web-react#107.

[jimbojetlag]

Thanks, I did not know that there is that distinction between application and library code.

The use of the experimental features in @material is based on a decision, it is not a mistake. They do however provide a compiled version of their code, that can be imported from the dist/ directory. But it feels awkward to import generated code during development.

I understand that CRA is trying to be highly opinionated, but some of these opinions seems to fall out of the scope of React itself. In my opinion, CRA should be be opinionated in the relevant scope, and not try to babysit its users when it comes to making decisions outside of that scope.

For example, folks at Google feel like the experimental ES features are here to stay, they are already writing code based on them. I, as the users of both Google's Material library and Facebook's CRA, should be able to develop without these frictions. If in a near, or far, future the experimental ES features are dropped, it will be a problem of Google Material and my application, and not a problem of Facebook CRA.

[gaearon]

folks at Google feel like the experimental ES features are here to stay

I think this might be a misunderstanding of some sort. I was physically present at a TC39 meeting just a few months ago, and I can assure you the current behavior or syntax of class properties was not by any means considered final.

I understand that CRA is trying to be highly opinionated, but some of these opinions seems to fall out of the scope of React itself. In my opinion, CRA should be be opinionated in the relevant scope, and not try to babysit its users when it comes to making decisions outside of that scope.

Respectfully, I understand your position, but the vast majority of the users of this library won’t know what they’re getting into (just like you didn’t). If the spec changes in half a year, and all of the code published using it will stop compiling in the next version of CRA that updates Babel, people will blame React and the React ecosystem for the churn.

And in a way, they’ll be right. Compiling third-party code with transforms specified by the app tooling is very fragile, as proven by years of watching frustrated React Native users (who adopted this approach and regretted it quite a few times). And beginners (who might not know how to run a codemod, or what to do when we break their code) will be hurt the most. Given that CRA’s goal is to make React easy to get started with, this seems like it a direct contradiction to its mission.

Being the only official project in the React ecosystem related to build tooling, I see it as our responsibility to try to ensure our users don’t shoot themselves in the foot, even if at the time they think it’s best for them.

[bidanjun]

as a example,for react-navigation,it's published as source code in npm. it use react-navigation-deprecated-tab-navigator, also it's publish using source code without compile,so
./node_modules/react-navigation-deprecated-tab-navigator/src/views/TabBarBottom.js
SyntaxError: D:...\node_modules\react-navigation-deprecated-tab-navigator\src\views\TabBarBottom.js: Support
for the experimental syntax 'classProperties' isn't currently enabled (26:23):

and is there any way to use it without eject?

[gaearon]

No and as explained above it’s intentional. I agree it’s annoying for RN projects that adopted a different stance but that’s something you can bring up with their maintainers.

[loopmode]

I think this can affect your own application code too, not just third party code - when using yarn workspaces for example. Maybe I'm just doing it wrong tho..

I have many packages in the workspace, and one of them is a CRA app that consumes the other packages. I just migrated my ejected CRA1 app to standard CRA2, so I fiddled around a bit.

I keep watching and transpiling the non-app packages with lerna and babel, transpiling their /src to /lib. The app then consumes their /lib.

So I just tried to change /lib to /src in the import paths to workspace packages, in the hope I might not need watching/transpiling anymore, e.g.
before: import Foo from '@client/components/lib/Foo';
attempt: import Foo from '@client/components/src/Foo';.

But it's not possible due to the Support for the experimental syntax 'classProperties' isn't currently enabled problem. Where it actually works just fine for both the app and any package individually (packages extend the babel and eslint configs "provided" by CRA)

Makes sense, as it "looks like third party code" from the app's perspective. @gaearon Any tips on how to proceed in such a yarn workspace scenario besides transpiling the individual packages? I'm googling the topic for weeks now, with no real success. I might be asking the wrong questions.. :)

[bugzpodder]

@loopmode If you have code in a workspace, it is treated as third-party code and you'll need to transpile it like you were doing. ie keep /lib/Foo