Sharing components between apps, "create-react-component"

[ericvicenti]

Note from Maintainers: see #1492 (comment) for the latest thinking on this.

The Problem

Say I have two sibling CRA apps, Foo and Bar. What is the best practice for sharing a common component, Baz between the two apps?

Scope

It would make sense to have a sibling folder Baz with it's own package.json, and to use npm link to access it from Foo and Bar.

But it seems that npm link has bigger issues, so maybe we should explore alternatives. One example is wml, which simply watches and copies files.

Building

Even when npm link works fine, the JSX in Baz has not been compiled.

Per this discussion, I think we should compile separate modules like Baz independently, but that will require boilerplate such as babel config. CRA helps avoid this for full apps, but we don't yet have create-react-component to help manage the boilerplate of shared components.

Optimizing for Developer Experience

There are a few ways to clean this up, but I'm curious what people think is the current best practice. What is the ideal developer experience?

[bvaughn]

Prior art worth considering: insin/nwb, specifically Developing React Components and Libraries with nwb

[ericvicenti]

Ah, I hadn't seen nwb. It looks like a smooth experience!

Does it make more sense to add integrations and compatibility with nwb new react-component? Or should we make a create-react-component that stays in sync with CRA? It could live in the same repo and share configs like babel.

There are a few things that I would have done differently for CRC, in comparison to nwb new react-component:

• Use jest instead of mocha, for consistency with CRA
• No questions at init time (convention over configuration)

[gaearon]

A few past issues:

#423
#796
#907
#1242

[izakfilmalter]

I can't stress how much I need this feature. My core problem is I have 3 apps: marketing-site, 'customer-app', and 'employee-app'. I am keeping them separate to make them as performant as possible, but there are many shared components, for instance the logo.

My current solution has been having a fourth app that gets imported into each, and then using yarn link, but as mentioned above this is painful, and has issues.

With each layer of separation, my development experience goes down. Having this built into create-react-app would significantly simplify my life.

[Timer]

What artifacts would such a feature produce? CommonJS, Harmony Modules, UMD, AMD?

[natew]

Something I've been wanting/thinking about for a while now. There are actually a few levels you can look at this:

1. I want a CLI that links together all my local node projects I'm working on (like system-wide lerna)
2. I want something that shares my common scripts/settings between my projects (like CRA)
3. I want something that manages multiple projects (shows their status, pulls them all down initially)

There are some pretty complex considerations I think in here. We have a big stack right now with about 25 packages inside it using lerna. But I'd love to release the 8 or so that are more ready for public consumption.

Problem is, I don't want to sacrifice all the niceness of using Lerna now: shared configs, always in sync, can edit them locally easily, automatically linked together.

So, I've just started on repoman which honestly I'm not sure how will solve all this stuff.

My initial idea is to let your packages define a repoScripts key that points to a github repo, which then has some shared dotfiles/scripts that can be run. Will check into nwb more. If it only handled auto-linking things together + easy standardized/ejectable configurations would be nice.

[tbillington]

@izakfilmalter It's not ideal but here's my solution #1084 (comment)

[ericvicenti]

Ok, @gaearon, based on your previous comments, it seems that this issue is pretty ripe for fixing.

RFC of a cohesive solution

Please poke this proposal full of holes 😄

Part I: The new meta Creator

We may want to give people more tools like CRA in the future, but it isn't desirable to force people to install a new global dependency for each tool.

Instead, I'd like to propose one tool to rule them all: create-react:

npm install -g create-react

# This is equivalent to `create-react-app MyApp`
create-react app MyApp

# Now we can support:
create-react component Foo

Behind the scenes, this tool will look up the latest npm package to do the heavy lifting. For example, create-react app actually is implemented by the react-creator-app package. The react-creator-component package would define the behavior of create-react component.

This opens up more innovation in the space, because a random company could publish react-creator-mycompany-project, and everybody can easily try out their environment by running create-react mycompany-project.

Also, this could replace react-native init, which could become create-react mobile, create-react native or something.

Part II: The Component Dev Setup

One of the new creators would be the 'component' creator, which creates a new React component package.

Like a CRA app, it includes scripts as devDependencies, and has local commands like npm run build, which builds using the standard Babel configuration. It would output whatever module standard is expected by standard CRA apps.

One major difference is that npm start will build the component and watch for changes, rather than launching a server.

At this point, developers could use npm start alongside linklocal to hack on their components from a neighboring react app.

One huge argument for doing this is to improve tooling for React Native components. Currently, most RN libraries publish uncompiled code, which has become a nightmare when attempting to share libraries or components in other environments that expect node_modules to be compiled. By introducing a common set of library scripts, we can build a comfortable path forward to compiled modules.

Part III: Improve experience within an app

The only bad part about the above experience is the manual usage of linklocal and the npm start for each component you may want to hack on.

In the future, the react-scripts of CRA could be upgraded to automatically run linklocal, so that changes made in neighboring modules are immediately reflected in the development app.

Then, react-scripts can detect when an app's linked component is supported by the same scripts, and can automatically run the watch-and-build behavior for each of the compatible components.

So, if I had Foo and Bar as independent apps that each depended on a sibling Baz component, I could run either app and still see the updates as I make changes to Baz.

Thoughts?

Let me ping a few more smart people who have a lot of context on this: @cpojer @thejameskyle @skevy @taion @ljharb

I'm excited to work on this because I've felt this pain a lot- especially when trying to share code between React Native and web/CRA.

Please let me know if you think this makes sense! I'm happy to put together a prototype, if people like this approach.

[ljharb]

I'm not sure I understand - isn't the solution to sharing Baz between two apps, "publish it to npm"? npm link is fine for developing, but something that works across two apps deserves to be a separate package - if not published publicly, then to an internal npm registry (sinopia is free, for example, and using an npm registry gives you semver benefits that git installs don't).

Can you help me understand what the problem is here that needs solving?