-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sharing components between apps, "create-react-component" #1492
Comments
Prior art worth considering: insin/nwb, specifically Developing React Components and Libraries with nwb |
Ah, I hadn't seen Does it make more sense to add integrations and compatibility with There are a few things that I would have done differently for CRC, in comparison to
|
I can't stress how much I need this feature. My core problem is I have 3 apps: My current solution has been having a fourth app that gets imported into each, and then using With each layer of separation, my development experience goes down. Having this built into |
What artifacts would such a feature produce? CommonJS, Harmony Modules, UMD, AMD? |
Something I've been wanting/thinking about for a while now. There are actually a few levels you can look at this:
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 |
@izakfilmalter It's not ideal but here's my solution #1084 (comment) |
Ok, @gaearon, based on your previous comments, it seems that this issue is pretty ripe for fixing. RFC of a cohesive solutionPlease poke this proposal full of holes 😄 Part I: The new meta CreatorWe 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: 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, This opens up more innovation in the space, because a random company could publish Also, this could replace Part II: The Component Dev SetupOne of the new creators would be the 'component' creator, which creates a new React component package. Like a CRA app, it includes scripts as One major difference is that At this point, developers could use 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 Part III: Improve experience within an appThe only bad part about the above experience is the manual usage of In the future, the Then, So, if I had 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. |
I'm not sure I understand - isn't the solution to sharing Can you help me understand what the problem is here that needs solving? |
@ljharb, I don't think most people who use CRA know about sinopia. If that is the recommended solution, then we can at least do a better job on education. Lots of people seem to like the lerna approach, and/or linklocal. Aside from the reported issues about And yes, publishing is another aim. If we have a CRA-like thing for react native components, we can fix that problem you always rightfully complain about: the RN ecosystem is publishing tons of uncompiled modules that is wreaking havoc on people who try to share code between universes. If we encourage them to use our devDependencies and scripts, their published library/component/nativeModule can easily evolve with best practices. For the rest of the React ecosystem, it may be handy to publish a component without any build configuration. |
So I would (personally) summarise the problem domain as the same one as create-react-app, just with respect to painlessly creating a component without any of the build concerns etc as @ericvicenti has stated. Having previously used sinopia (not picking on it) - but its now not even in maintenance mode (last commit was over a year ago) rlidwka/sinopia#376 and it is a solution that adds another cog in the toolchain rather than making it easier to develop imho. |
Why not just:
Run the packager from the root (Projects), when bundling it will only include files that are used. E.g. if SharedComponent.js is only imported / required by app2.js, it will only be included in app2's bundle. If SharedComponent uses a 3rd-party dependency, all apps using ShareComponent should include that dep in their package.json. |
@mkonicek, there is no Also, what if @admmasters, yes exactly. My aim is to deliver a good development experience for standalone components, just like CRA delivers a great dev experience for apps. |
@gaearon, does the |
I like the solution discussed in #741: Remains just the problem of using it in another app. Some node/npm related solutions mentioned above (publish, sinopia, link local, NODE_PATH) could be just fine. |
@ericvicenti It's related but it's solving a slightly different problem: avoiding relative imports inside the project rather than sharing components between projects. Since people don't use Haste in open source, they have this issue of |
@bebbi, I'm still confused. What would my directory structure look like? I need two independent apps "Foo" and "Bar", which each share a component "Baz". Baz may be an independent repo, but I would like to easily edit it while developing my Foo and Bar apps. @gaearon, Gotcha, I agree that the problems are related and should be thought about together. I'm spoiled by using Haste at FB. Its not perfect but it means we never worry about this sort of thing. |
It's a partial solution for your scenario. But with the assumption that often one project is driving any given components dev, it might still be a nice one.
and |
I use git submodules to share components placed in |
Ok, it seems that there is enough support to give this a try, so I'm going to implement parts one and two of my proposal as a PR to this repo. That way we will have |
I heartily recommend including react-storybook in any component tool: you could have |
I'm a bit late to the party but I think WebPack (and now the React Native packager too) support symlinks? So with this setup:
Can I just 'npm link' the |
@mkonicek, yes but how will you configure the build for those shared components? Also, |
my case: I have project with component "react-lazy-load": "../../../react-lazy-load" in UPD: so CRA solution is to use this cd ../..
yarn link
cd examples/basic
yarn link react-lazy-load which is not that nice solution in that case UPD2: endep up with using symlink |
+1. Kind of blocked by this issue. |
Man I hoped there would be a solution by the time I scrolled to the bottom. Boy, did my dreams shatter. To be clear, I just want to publish packages from create-react-app without the need of reusing webpack configs and other scripts etc. Well, hope @ericvicenti's PR will help, in the meantime I'll have to copy all my configs =( |
Guys, solution is here. Assume you have 3 React apps:
cd to root directory of GoodComponent Here we go! You can now have your own temporary npm module. You can reuse it just as an npm module without publishing it. |
Using Forget the part about "and share it in npm", just check how the example works (it's sharing the component using |
@shiyang-fei it's not a solution if you want internal components published to internal repository |
@shiyang-fei not really. When I say internal repo, I mean we have a private npm registry from which we distribute packages to different teams in the company. And doing the whole webpack routing for every little shared component is just tedious. I only need the publish feature, that's all. |
Yes, by implementing a proof of concept addressing all the different issues in this thread. It is very unlikely we'll get time to work on this, so it's really up to the community. |
We made some progress on repoman a while ago, but haven't touched it in a while. The structure of the project itself though is laid out well for someone wanting to fork. It's basically a lot of Lerna but instead of per-project, it's per-computer (it controls a folder for you, default is So Then you could have a monorepo and run It also has a subset Lerna functionality baked in, so you can have it cross-link and install and such. It needs some love in terms of someone taking care of it, testing it it and probably patching a couple things and focusing it's scope. |
What about webpack alias: {
'my-local-package': path.resolve( __dirname, '..', '..', 'to', 'local', 'modules', 'MyPackage', 'src' )
} That work for me. Just and to {
loader: 'postcss-loader',
options: {
config: {
path: 'path/to/postcss.config.js'
}
}
} Also i add package.json and babel config for each local module. |
My colleague tried yarn workspaces to share code between projects and he used the following steps:
He did however tried thess starters (https://github.com/emyann/typescript-webpack-starter, https://github.com/vikpe/react-webpack-typescript-starter) and they work. Does anyone know what could be the cause of this? |
For anyone who ends up here an looking for a good React library starting point that uses |
I just submitted a proposal (#3436) that I think could support the original use case called out in this issue and some others that have come up in this thread. The proposal is to allow apps to specify additional source roots in package.json. The app can then import the "shared" modules as absolute imports and they are treated the same as if they were under /src (transpiled, etc.). monorepo |--app1 |--package.json: srcPaths: ["../shared"] |--src |--file.js: import comp1 from 'comp1' <-- ok, shared/comp1 |--file.js: import comp1 from '../../shared/comp1' <-- fail, not permitted |--app2 |--package.json: srcPaths: ["./components", "../shared"] |--src |--file.js: import comp2 from 'comp2' <-- convenience absolute import, components/comp2 |--file.js: import comp1 from 'comp1' <-- from shared/comp1 |--components |--comp2 |--shared |--comp1 The proposal is implemented, a working monorepo and more info is here: https://github.com/bradfordlemley/cra-share Update: @arnihermann -- Just realized this basically implements what you had proposed earlier in this thread. Wondering if you have already done it this way and if you've run into any issues doing it this way? I agree with your comments about publishing/linking/building/complication being an issue with some other solutions. Update2: added convenience absolute import example (in app2 above) |
Hi, any updates? |
I'll close since so far nobody took ownership of this.
No, if there were any updates, they would be on this issue. |
(that said, I think #1333 is still on the roadmap and is sort of related) |
I think the most recent thinking on this is:
Hope this helps! |
I just wanted to chime in here, it was pretty easy for me to set up a tiny webpack build, and just leverage the react-scripts setups from inside a fresh create-react app.
Here's the webpack.config.js file.
I split my https://github.com/sorahn/react-fuse edit: added link to github repo |
Also, begin switch from npm/yarn link to yalc for local dependencies. Npm link is broken in so many ways. It's really embarassing that sharing React components between multiple apps is still so difficult. npm/npm#17287 microsoft/TypeScript#6496 facebook/create-react-app#1492
The Problem
Say I have two sibling CRA apps,
Foo
andBar
. 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 ownpackage.json
, and to usenpm link
to access it fromFoo
andBar
.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 inBaz
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 havecreate-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?
The text was updated successfully, but these errors were encountered: