![]() Yarn will hoist common dependencies from each package of your repo to the workspace root node_modules, creating a single yarn.lock file. Yarn does this through a process called hoisting. Yarn will use a single lockfile rather than a different one for each project, which means fewer conflicts and easier reviews. All your project dependencies will be installed together, giving Yarn more latitude to better optimize them. This is also a better mechanism than yarn link since it only affects your workspace tree rather than your whole system. YARN WORKSPACES What is it and why should I use it?Īccording to classic.yarnpkg: Your dependencies can be linked together, which means that your workspaces can depend on one another while always using the most up-to-date code available. If you are just working on the RN app, you have to check out the whole monorepo, which takes up more disc space compared to just checking out the RN repo.If everything is in one repo, it’s more complicated. a separate repo for the API and the client), you can specify different access rights for each one. Normally, when you have separate repos for each package (e.g. No way to restrict access only to some parts of the app.Most tools for RN don’t have sufficient support for monorepos. More complicated CI/CD setup (but seamless once you get it right).For example, if you change the name of a constant that is shared between your web app and your server, you can immediately see all the effects of the change in your IDE. Best used when grouping related packages and their shared dependencies.Easier cross-package changes: one git PR instead of orchestrating PRs in different repos.Visibility of an entire project's codebase.You don’t have to manage separate repositories and do complicated continuous integration, versioning, and management. When you create a pull request (PR) in GitHub, it contains all the changes in all the packages in one place. if your "web" and "mobile" packages both use a "core" package). It is most beneficial if some packages share common dependencies (e.g. This kind of structure is beneficial for NPM workflows when you have multiple packages that you are regularly publishing. You can combine all these child projects into one repo to make them easier to maintain. a standalone package with its own package.json file). You will see how to build a small monorepo which contains the following:Ī monorepo is a single GitHub repository where you can have multiple projects, each with a separate set of dependencies (i.e. Various challenges are described with an explanation of how each one was solved. The video is a step-by-step guide to setting up the monorepo on a simple, practical example. There are several approaches which can be applied to different setups, whether you have a stand-alone (CRA) or a monorepo with different CRAs. If you don’t have the exact same setup that’s in the video, don’t fret. When I tried, Google returned over 20 hits containing various workarounds-most of which weren’t compatible with the latest version of RN at the time. You could google it, but you’ll just end up creating more work for yourself. The focus of this article and video is on the pain points you may encounter while combining React Native (RN) and web-based Create React App (CRA) with TypeScript in a single monorepo.
0 Comments
Leave a Reply. |