Importing Sibling Workspace Source

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.

[SavePointSam]

The source support feature is being tracked over on https://github.com/facebook/create-react-app/issues/4092

[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.