We have 3 react apps. Some of the components being used in these apps are common for the 3 apps. We want to have a separate common git repo, where we can put the code for the common components and use those components in the 3 apps. Currently, we do have a repo for common components which is linked from the 3 apps like this in package.json:
package-name username/repo#commit-id
This arrangement poses some difficulties:
For some reason, hooks don't work in the common repo even if we upgrade the react version.
While developing locally, we change package.json to package-name ../path. Everytime we make a change locally in the common repo, the common repo has to be built again manually.
Overall, the process is not good. Many times it throws strange errors which are hard to solve.
Can you suggest an alternative way to accomplish the same?
For some reason, hooks don't work in the common repo even if we upgrade the react version.
Treat the component package as its own project. It should have its own package.json that declares its dependencies.
It sounds like you are trying to develop the component package at the same time you develop the other projects that use them. Instead, you should develop the component package in its own environment. If you find problems or think of new features to add to the component package while you work on a project that uses it, create new issues for the component package project and work on them there.
The projects that use this component package should declare a specific version (either by a tag or a commit) which they use. Upgrading to a new version of the component package should follow the same process as upgrading versions of a 3rd party package, such as React itself.
Related
I'm new to react development. I'm currently using Typescript for react with webpack and npm.
i'm working on a large scale project where components are complex. As of now they are kept in certain hierachy in project folder.
i recently learn about making components library. I'm thinking of taking complex components out of project and put them in a separate component library. However, other team members say it would cauae headache to maintain library separately. since there is less to no chance of using this in any other project (thats the current situation) they should not take the components out and maintain separately.
i want to know if that is the only reason the react developers create component and creating component to test it better and simplifing thw project complexity are not the valid reasons?
Recently, I joined a new company and found there are lots of outdated project dependencies e.g react-navigation#2.x.x, react-native-firebase, react-native etc. Now I want to upgrade all of them. Now another concern is rest of four developers are doing there on outdated packages.
So what would be the best approaches
Thanks in advance
I recently experienced the same thing. And here's how i dealt with:
You must talk to those devs and get approval for upgrade. Then you must select a day with no development to upgrade because every new commit will introduce conflict, weekend would be best.
Backup the project to multiple places, if you make something terrible, even remote git repo might not help you.
Upgrade react native first. Recent versions of libraries depends on the new technologies of react native. For example reanimated 2 requires rn > 0.62.
You can use React Native Upgrade Helper to see what has changed. If your project doesn't use too much custom native code you can even create a new empty react native project and copy necessary files.
Test your app in android & ios to see upgrading react native didn't break anything.
Then look into every dependency to see what has changed. You're in luck if you can find a migration guide (something like this: https://reactnavigation.org/docs/5.x/upgrading-from-4.x).
Some libraries like react navigation, react native reanimated changed drastically. These kind of libraries would be the most of your work, especially reanimated. Test and backup project after every library.
And you should be done. Test your project again for every screen / every method.
If you're 100% sure project is running as expected, you can change / create new tests and merge your changes.
First of all, thank you for reading and trying to understand this question.
In my team we have built a library for common Components with React for about 2+ years. This library is built with Babel creating two different transpilations. One in CommonJS for our Test Runner to run tests (because Jest cannot use ESM) and another one in ESM for Create React App (Webpack inside) to make Tree Shaking possible. We use Create React App to build and develop our Apps.
This is working for us perfectly. But we have encounter a problem when managing Final Form Peer Dependencies (or any other library). This is our scenario:
Common Components Library
PeerDependencies
Final Form
DevDependencies
Final Form
App1
Dependencies
Common Components Library
Final Form
App2
Dependencies
Common Components Library
Final Form
App3 (It dont use FinalForm but it uses other Common Components)
Dependencies
Common Components Library
I'll explain this:
In our Common Components Library, which I spoke earlier, we have React Components that works with Final Form, like for example a Vitaminated Autocomplete Text Input Component that we share among many Apps. This Apps also use Final Form to create Components that implement forms locally for that App.
So App1 is right. Everything works fine. But for one thing, now if we want to upgrade Final Form version for this App because, lets say, we need a bug fix of Final Form. We are been forced to upgrade also our Common Components Library and the other App's Final Form version. We need to do this if we want to avoid execution errors within the Final Form React Context. If you are familiar with Final Form or React Context in general you probably have encountered this problem. You can't use different versions of a library that uses React Context. i.e: if we have final-form#1.2.3 in our Common Components Library and final-form#1.2.4 in our App1 it would genereate an execution error. So as I said, we are forced to upgrade not only on App1 and Common Component Library also on the other Apps that uses a Common Component on the Library that uses Final Form. The statement would be: 'Now, if we upgrade somewhere we have to upgrade everywhere'. And we don't want to do that. Probably we aren't handleling dependencies correctly.
So this drove us to move Final Form dependencies (we also use react-final-form, final-form-arrays, etc...) to PeerDependencies. Our problem was solved. But now, another one appeared when we saw that in Apps like App3 we were having an error when we build our App3 with Create React App. This is our output when using npm run build:
module not found `react-final-form' in file 'node_modules/CommonComponentsLibrary/VitaminatedAutoCompleteTextInput.js'
This means that, even with our App not using this VitaminatedAutoCompleteTextInput when we build its checking for every import in the node_modules so this is making us unable to build our App3. When we add the 'missing' depednencies to our App this builds with no problem and then when analyzing our bundle with source-map-explorer we see that final form depdenencies are not included in the bundle.
Is this necessary? I felt like we are missing something here. One solution for us has been including final form depdnencies on the Common Components Library as 'normal' dependencies but we were still having the first problem I mentioned before.
Maybe this problem is not only related with Create React App or Final Form. This is probably a more global isse within ESModules Libraries with Npm dependencies. Probably you will need me to enchance the explanation or have questions. I'll be glad to improve this question where needed. I have also searched on Google and here to find a similar question but I only found this. I dont know exactlcy if it's the same question but It have no answer yet.
Many thanks for trying to help or understand this issue,
I am building a monorepo for a suite of React apps, and common library code. One of the packages would be a component library.
packages
app1
app2
common-ui
alert
button
I'm pretty new to the whole React/node ecosystem.
I've looked at a lot of actual UI library examples - react-bootstrap, material-design-components-react, etc.
It seems I would want to have each component in the common-ui lib to be distributed as single files, so that they can be cherry-picked when imported into a consuming app.
react-bootsrap does this by using babel to build the "lib". They build into a browser distributable, a commonjs lib, and an ES lib.
material-design-components-react does this by having their component lib itself by a lerna monorepo, with each component having its own package.json, and I believe they use webpack to build each component individually.
So my first question is,
Is a structure like material-design-components-react in my common-ui folder - kind of a monorepo within a monorepo possible?
Or would I have to restructure:
packages
app1
app2
alert
button
My second question is,
Which design is recommended by the community for a component library within a major monorepo? This must be a common structure developers have to solve when they have many client apps with common libraries. A package per common-ui component seems like a lot of overhead, but of course they have scripts to help out.
Is a structure like material-design-components-react in my common-ui
folder - kind of a monorepo within a monorepo possible?
Yes it's possible. But keep in mind, you and those libraries have very different requirements. You can think of your monorepo as small projects developed in same company., which are depending on similar 3rd party libraries and they follow same linting, testing etc.
Which design is recommended by the community for a component library
within a major monorepo? This must be a common structure developers
have to solve when they have many client apps with common libraries. A
package per common-ui component seems like a lot of overhead, but of
course they have scripts to help out.
First structure with 3 packages is most common way to start your repository/project.
In your case, I wouldn't recommend to divide your ux-library into single files. Your apps will likely use most of your ux-library and probably you won't have as much components as material or bootstrap has. Moreover, if you'd ever reach that point in your library, you can separate them later. For reference you can also check how lodash is publishing each of their functions. It's not different than your case (assuming you won't publish any fonts/images etc.).
I'm new to Aurelia and I want to create an app that call for other apps.
Example : I want to create 3 projects, project A, project B and common and wish to call common in both projects A and B.
I've tried some examples with npm and others, but this never works.
Is there a simple way for doing that ?
Best way to utilize your common features for your 2 projects is to use an aurelia plugin.
Aurelia plugins are very good at encapsulting reusable components.
JSPM, the default package manager for Aurelia, supports private github repo and even local ones (easier during the early development phase).
So intalling your plugin in your project will be as easy as typing something like that :
jspm install github:mygithubaccount/myplugin#master
I would advise you to start reading one of plugin authoring blog post, then check the repo plugin to see how to package yours.
Check the blog post about AureliaFlux, it is worth reading.
You can also use the aurelia skeleton-plugin repository as a starting point.
Good luck.