Importing Sibling Workspace Source

[SavePointSam]

Is this a bug report?

No

Problem

I'm using lerna and yarn to manage a set of packages that make up our frontend. I want to import an internal UI toolkit (uiKit) into my CRA-based app (app). However, I'm unsure how I go about importing uiKit in such a way that I don't need to commit / manage a distributable that previously only existed in a private NPM package (how it was imported before the monorepo switch). While I don't think this is directly a CRA issue to solve, I needed a place to start and @gaearon asked me to open a detailed issue here.

I use the same babel settings as CRA in uiKit, but CRA doesn't transpile anything it believes is in node_modules. However, in react-scripts@2 there will be support for fundamental transpiling node_modules, but this is for known language features, not things like flow, so no luck there.

The only solution I've found so far is to manually build uiKit and then commit the distributable. This leads to a clunky developer experience as they may be working on uiKit and app at the same time but not seeing updates from uiKit update in app in any sort of real time. They would need to manually rebuild uiKit and restart the app server to see changes reflected. IMO, this defeats the purpose of using lerna to access indev packages without explicit build steps.

Folder Structure

Current

frontend
└── packages
    ├── uiKit
    │   ├── build
    │   │   └── uiKit.js
    │   ├── src
    │   │   ...
    │   │   └── index.js
    └── app
        │   ...
        └── src

Desired

frontend
└── packages
    ├── uiKit
    │   ├── src
    │   │   ...
    │   │   └── index.js
    └── app
        ...
        └── src
            ...
            └── index.js

Other Thoughts

Maybe I'm looking at how I import my UI library wrong? Although, IMO it should work just the same as if the uiKit components we inside the source for app. Maybe there is something I missed in the lerna set-up that would fix this? It would be nice if I could have it run the packaging process and symlink that instead of the source itself? Although it would need to run on every change which would be heavy and a running CRA dev server wouldn't see the update anyway AFAIK. There might not be any solution other than committing the distributable, which is really unfortunate. I could configure a setting so that CRA thinks that it's not actually a node_module in some way and it will transpile as expected, but I have no idea if that is even possible.

I looked into providing a different package.json attribute that would represent an entry point that hasn't been transpiled, but all the attributes are based on the expected module definition type, not the state of the code itself. I could symlink the uiKit components into the app source but thats even messier to maintain.

I'm at a loss at what should be done here. I want to keep my component library separate for usage in other places, but also don't want to explicitly build and commit the distributable to enable seamless cross-package development.

[bugzpodder]

Hi @SavePointSam I am currently running exactly what you described having a UI and a separate app which uses the UI source code. You'll need to setup yarn workspaces properly and it should work as expected. The use of lerna is not required.

Here is my package.json if it helps you:

{
  "private": true,
  "workspaces": {
    "packages": ["client", "ui"],
    "nohoist": ["**/babel**", "**/eslint**", "**/jest", "**/webpack**"]
  }
}

[SavePointSam]

@bugzpodder Thanks! Lerna automatically sets up workspaces for me, so I shouldn't have to do anything. However, there is an issue on the react-scripts@2.0 roadmap item that also deals with this, #1333.

[bugzpodder]

Yep, if you use the latest version of CRA2, you should already have proper yarn workspaces support. If you are running into trouble, checkout the user guide in CRA2 to see if you missed a step.

[bugzpodder]

@SavePointSam are you still having issues setting up your repo? As I mentioned before I have been using the setup with no problems. Let me know if you need any help on this by provide additional details on your config files and versions of the tools.

[SavePointSam]

@bugzpodder Thanks for the support! However, I have had the basic set-up working with CRA 1 no problem. My real problem arises in a situation that is not yet supported. I've had a couple of discussions with Dan over Twitter about it. It appears we need to follow through on this issue #4092. I'm hoping to work on this in the near future and get it working before the proper CRA 2 release.

[SavePointSam]

I'm actually able to accomplish this by using CRA 2 and swapping my uiKit main to my source index for the time being. I would like to finish up the proposal to support source before react-scripts@2 lands.

For the time being I'll close this issue as I am happy with my current solution while we work on a better one. There was one other issue I had where ESLint was trying to run against my uiKit bundle though. I'm not sure how much of an edge case that will be in the future, but worth noting for now I think.

[SavePointSam]

As a note: my solution only works because I subscribe to having the same babel settings in both my CRA app and my uiKit. So your milage may vary if you're using different plugins or settings.

[SavePointSam]

The source support feature is being tracked over on #4092

[bradfordlemley]

@SavePointSam FYI, CRA2.0 does already support source packages throughout the monorepo, like in your example above.
It has some limitations, though:

• Can't opt source packages in/out (see react-scripts 2.0 breaks some monorepos #4569)
  ** One way to fix this is Require monorepo source workspace packages to be opted in via glob. #4570 which uses a glob pattern to opt packages in.
• No way to specify the "source" directory, which means that your uiKit source would have to move to root instead of /src (or you could specify "module": "src" in uiKit's package.json, though that would probably be considered abusing "module").
  ** This functionality could be added to the existing implementation.

#4092 is an alternative approach to fix the opt in issue (and also specifies that the "source" entry point should be supported, so it would fix that issue, too).

[SavePointSam]

@bradfordlemley thanks for the detailed overview! I'm actually in the process of assisting with those efforts. I totally agree that workspace/monorepo support should be opt in and have it's own section in the guide before the launch of CRA 2.

For now I'm abusing the main field in my package.json to have it think that the src/index.js file is the file usable output. This is ok for my use case right now as uiKit is an internal library and we are ok adding the overhead to make sure we fix the hack upon proper release.