const fs = require("fs") Ĭonst getDevPaths = require("get-dev-paths") It was perfect for us, because the app-shared package is a symlink for app-native but its real path is in app/packages and not in some other node_modules directory. In this file we used a development node packages called get-dev-paths, this package will return the node modules which are symlinks and their real path it’s not in another node_modules directory. We fixed this by telling to metro packager to watch the rest of the monorepo packages using a file. More specific, only the app-native project was watched for code changes. The problem was that metro didn’t know to look for code changes in both projects. For example the app-native project had most of the backend code from app-shared project. Metro and SymlinksĪnother big challenge was to make metro to look for changes in all packages that depend to a specific package. These two lines will do a shallow and deep no hoisting for all package names that contain the “react-native” characters. Next step was to do the same thing for all react-native dependent packages: "**/*react-native*", It will do a deep no hoist, this means that all the dependencies related to the react-native package will not be hoisted. To resolve that, the second line comes into play: "**/react-native/**", This is called shallow hoisting, because it will only no hoist only the react-native package but its dependencies will be hoisted. Tells to yarn workspaces not to hoist the react-native package no matter where it is. This can be done by adding in the package.json file from app workspace a nohoist property with the following rules: "nohoist": [ Fortunately yarn workspaces has a way to define which packages to be hoisted and which not.įirst thing was to tell yarn workspaces to ignore the react-native package. We all know that React Native does not support symlinks, this was a big problem because our monorepo packages were not recognized by the React Native packager. ![]() That dependency will be moved in the node_module directory from project’s workspace and a symlink will be created & added in node_modules directory from each project. Yarn workspaces tries to optimize the node_modules directory by sharing common node modules between projects, in this way if app-native has the same dependency as the app-shared. That directory will contain all the shared dependencies. We don’t have a lerna.json file anymore and a new node_modules directory has showed up. The new project structure was looking like this: ![]() With lerna, our monorepo project was looking like this:Īfter removing lerna we obtained a much cleaner look. Lerna is a great tool to manage monorepos, besides the lerna bootstrap command we didn’t use any of its features, so we thought that yarn workspaces will be a better fit for our needs because it was simpler and it’s more mature now. Here are some stories about the most difficult things that we encountered during the upgrade. In this article we will focus more on some specific problems related to Lerna, Yarn Workspaces, Metro bundler and symlinks. This tool helped us to see what we need to change to be able to use the latest version of React Native. ![]() Depending from which version of react native you start to upgrade there are a lot of things that need to be changed, added or removed.Įach scenario can be different, that’s why we highly recommend to use rn-diff-purge. You already know that a React Native upgrade is not an easy process.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |