Babel JSX Syntax error when importing from a linked library

[FelixKuehl]

Is this a bug report?

Yes

Did you try recovering your dependencies?

Yes

Which terms did you search for in User Guide?

(Write your answer here if relevant.)

Environment

Running npx create-react-app --info does not seem to work. Getting:

Please specify the project directory:
  create-react-app <project-directory>

For example:
  create-react-app my-react-app

Run create-react-app --help to see all options.

However I am using:
Node v8.11.3
Yarn 1.9.4
npm 6.4.1
react-scripts 2.0.0-next.2150693d

Steps to Reproduce

1. Create a new Create React App (The actual App)
2. Create another Create React App (The "Library")
3. Link them together: Import a component from the Library into the App

This used to work with react-scripts 2.0.0-next.a671462c

Expected Behavior

The app should compile just fine as it used to in 2.0.0-next.a671462c

Actual Behavior

Application fails to compile with "Syntax error: Unexpected token" in the component, that was attempted to be imported from the other application.

To me it seems like the babel loader is somehow not transpiling the imported component.

Reproducible Demo

https://github.com/FelixKuehl/cra-alpha-issue-example

[gaearon]

Hey @FelixKuehl, we're really sorry about this! As mentioned in #5024, our monorepo support was incomplete and we think it would create more issues for our users in long term if we shipped it in that state. On the other hand, the 2.x branch has stalled for many months, and we were worried it would never get shipped. So we made a difficult decision to remove some of the features that existed in 2.0 earlier alphas in order to ship a stable 2.0 within two weeks.

We'll offer migration strategies that you could use to unblock your migration to 2.x, but they'll likely include introducing another compiler like nwb for packages outside the main one. We are also open to more proposals about monorepo support, except that if we land it next time it would need to be a more complete one.

[FelixKuehl]

Hey @gaearon, thank you for your fast reply. This actually is quite a bummer for our current setup. We did enjoy developing cra powered applications in a monorepo due to the flexibility and the productive development workflow it gave us. Personally I have no experience with nwb or similar. Wouldn't it be possible to at least support Yarn Workspaces to be able to share components between applications? I feel like this is quite an important feature when developing multiple applications, that have shared elements.
Do you have migration proposals written down already? Having to use an intermediate compiler feels like it would come with a lot of configuration work and some serious pitfalls.

[gaearon]

Yeah I understand why it's useful very well. It was just half-baked, especially with regards to how testing works, or how to opt out certain packages from compilation.

@Timer can give you some pointers.

[FelixKuehl]

@gaearon Thanks for explaining. I will take a look at projects like nbw and create-react-library to transpile our library code. I am especially worried about sass and css-modules. Would be great to get a hint on your future roadmap / ideas regarding this topic. Every pointer would be helpful @Timer ;)

[Timer]

Hey @FelixKuehl! I'll probably be drawing up some more extensive documentation here soon.
I'll post here when it's ready.

[FelixKuehl]

As an Update for all those having the same issue:
I gave create-react-library a try and it did a decent job as a drop-in solution without a lot of manual adjustments.
However it comes with some caveats:

• SVG Images used in the library are sometimes not correctly resolved
• CSS Modules and SASS work out of the box. However it seems like all the css imported in any component within your library, is always getting included into your app. No matter which component you are importing from the library. A possible solution for resolving CSS treeshaking might be https://github.com/FullHuman/rollup-plugin-purgecss as referenced in Tree Shaking egoist/rollup-plugin-postcss#98 .
• Rollup does a pretty good job in watching and recompiling your code. The downside however is, that every code change forces the create react app that uses the library to recompile completely. Depending on the complexity of your application and your library, compiling both on every code change can take a painfully amount of time. So I would highly recommend using some kind of styleguide setup to develop your components against.

Another problem I stumbled across, that might be interesting for @Timer's migration proposals or create react app itself, was the way ESLint handles locally symlinked dependecies. With cra's current ESLint setup, everything within the "node_modules" folder gets ignored by ESLint as expected. However, if a dependency is symlinked locally (Yarn Workspace, Lerna, npm link, etc.) the path is resolved first and then checked against the eslintignore settings and therefore not excluded from linting. This results in ESLint errors showing up in your create react app when consuming a locally linkend library (Or more precisely its "dist" folder). A quick fix for this was using babel-plugin-eslint-disable. However I do not see any use case where you would want to lint a dist folder, so adding **/dist* to the default eslintignore would be a more defensive solution. Or am I missing something?

I will take a look at nbw now and see how this integrates.

[Timer]

Hmm, ESLint resolving symlinks sounds like a bug. Can we turn this feature off?

[FelixKuehl]

This bug is referenced in webpack-contrib/eslint-loader#165, webpack-contrib/eslint-loader#202 and webpack/webpack#985. I am not a webpack expert but setting symlinks: false in the webpack config or adding **/dist/* to eslintignore could work. Would need to test this though.

[FelixKuehl]

@Timer following @gaearon's suggestion, I spend the last day experimenting with nwb as a compiler. The setup I came up with, seemed quite decent to me. I put up an example repo here: https://github.com/FelixKuehl/cra-monorepo
Maybe this can help you out a bit or gets you some ideas for your documentation. Let me know if I can do anything to help.

So what did I do? (See https://github.com/FelixKuehl/cra-monorepo/blob/master/README.md for details)
Using nwb as a compiler seemed quite intuitive. However it did require some configuration in order to work with create react apps features, such as CSS Modules, SASS, etc. Also, I wanted to have a dev server / watcher, that handles recompiling on code changes.
All this can be found in the library-utils package within the example repository. These utils provide a nwb (and Storybook) config, that works quite well when the components are targeted at being consumed by a create react app.
In order to have a decent development workflow, I build the library-utils build:watch and library-utils start scripts. The first one starts a custom nodemon based watcher, that automatically recompiles the library on changes in the src folder and the second one starts this watcher together with a storybook server. This feels quite convenient when developing.
When having multiple libraries in the monorepo you can now simply run lerna exec -- yarn run build:watch to start a single terminal application that watches all the packages that have the "build:watch": "library-utils build:watch" script in their package.json.
The watcher simply transpiles all the components and copies the assets for the create react app to bundle.
Again for details just take a look at the linked example repository above or just ask me :)
Hope this might help a bit.

Update:

Form commit FelixKuehl/cra-monorepo@0d21eb5 on, this repo uses babel to watch and compile the libraries. Also I switched to using Styleguidist over Storybook.