For the apps/nextapp Next.js application, choose Next.js as the framework and apps/nextapp as the root directory.For the apps/frontend create-react-app application, choose Create React App as the framework and apps/frontend as the root directory.Use the following configuration for each Vercel Project: Deploy both applications to Vercel from this same repository by creating a new Vercel Project with Git twice and selecting the repository from the Import Git Repository section. We updated our config-overrides.js like this: const rewireYarnWorkspaces = require ( 'react-app-rewire-yarn-workspaces' ) module. We use react-app-rewire-yarn-workspaces to compile our shared code. exports = moduleExport įor the React frontend, we use react-app-rewired and already had a config-overrides.js file. This way, we can apply the same rules everywhere and lint all the project at once.įor this, you need a script like this: "lint": "eslint \" module. We moved our lint script and its dependencies to root. They were deleted from the workspace specific package.json.
#Yarn workspaces install dependencies update#
This was mostly done to ease update of these dependencies. We mutualized our common dependencies on the root package.json. Since all dependencies will now be installed in a single node_modules folder at the root of the project, we updated our CI caching strategy so in only restored it. We removed all the node_modules folder and yarn.lock and run yarn install at the root of the project to create a new (and clean) yarn.lock. We created a top level package.json the workspace configuration: "workspaces" :
See the official documentation for the migration procedure. It's good to reduce the size of Docker images. We mostly can install only the dependencies of one workspaces with the focus plugin. It wasn't required but was on our TODO list and it's easier to work with workspaces. That's the name you will use in Yarn commands and not the folder or path.Īll your dependencies will be locked at the root of your project with only one yarn.lock file. In each of these folder, you need a package.json to declare the dependencies specific to the workspace and the name of the workspace under the "name": "my-workspace". So, you put "frontend" to have a workspace at /frontend. It will have a workspaces key, set to an array of relative folders. In a nutshell, with workspaces, you will have a package.json at the root of your project. Since our needs are still basic, we only use Yarn and no extra tools (at least for now).
#Yarn workspaces install dependencies code#
It's an efficient, easy and standardized way to share code in a mono-repo.
With workspaces, you can declare folders on your file system as packages that can be installed and used directly in other project. So, we decided to use Yarn workspaces as a way to share code across our repository. We wanted to keep the mono-repository approach since it's a very good fit for us: the workflow is more simple and we can move faster. It's not a good idea and we were starting to have problems because of this.
Initially, we had some duplications between the app and the website. Today I'd like to dwell a bit on how we share our TypeScript code. You can learn more on this subject on monorepo.tools and Misconceptions about Monorepos: Monorepo != Monolith. So, this monorepo architecture is currently the best choice for us. We still can choose what to deploy and we only tests part of the project that works. This allows us to easily share code, to do changes in all projects easily at once when needed and to move fast. We have three projects: an API written in Python with the Django web framework, a big React app and a website written with NextJS.Īll these project are in the same git repository. I currently work in a small startup with two other developers.
0 kommentar(er)
