Local Development

In this page, chapter, we cover setting up the codebase and running it locally.

The codebase is structured as a mono-repo, which means it houses multiple codebases in one folder. pnpm plays a big role in facilitating this.

pnpm

An alternative to npm; it serves as a package manager, task runner as well as a mono-repo manager.

The reasons for using pnpm are:

• Convenience: When all the code is housed under the same folder, there's less overhead in navigating and editing code across both the applications
• Code sharing: Code that is common across both applications can be placed in a dedicated workspace and linked to each of the applications as a dependency, reducing the tedious and error-prone work of keeping everything in sync
• Space savings: If you have 10 projects on your system and they all depend on react, npm will install dedicated copies of react in each of the node_modules folders of all 10 projects. pnpm, on the other hand, only maintains one copy of react (in a global cache). All 10 projects simply point to this global copy of react.
  Hard links are created in the node_modules folder for every dependency and they point to the respective packages in the pnpm's global cache.
  Just as how the internet has hyperlinks to web pages, hard links are like that but for the file-system. pnpm won't add another copy of react for your new ReactJS project, it simply links to the central copy of react. This mechanism significantly saves hard-drive space.

pnpm also provides a framework to patch dependencies, which has been used for the following packages:

• @strapi/provider-upload-aws-s3
• strapi-plugin-webtools

The patches are stored under /patches/.

A patch is essentially like a git diff, specifying how the code in a package (dependency) should be altered. When the code is executed using pnpm, it correctly applies the patch to the package, overriding its code.

To install pnpm:

npm install -g pnpm

(We assume you have nodeJS installed on your system, else the npm command won't be available)

pnpm is a drop-in replacement (nearly) for npm. Therefore, all npm commands carryover to pnpm. Anywhere you'd use npm, simply replace npm with pnpm.

Here are some examples:

pnpm install react
pnpm install -D typescript

pnpm run dev

As you can see, they are nearly identical to their npm equivalents.

pnpm's monorepo features are however, unique to pnpm and differ from that of npm's.

Installing and Running applications

To install the dependencies across all the applications:

pnpm i
# OR
pnpm install

Every application has commands that are defined under scripts in their respective package.json files. So, for example, to run the dev command of the CMS application:

cd ./apps/cms
pnpm run dev

In the above command, we navigate to the cms application workspace, and then run the dev command with pnpm run dev (similar to how you'd do it if using npm).

However, with pnpm, you can do this instead:

pnpm -F cms run dev

The above command says, "Find the workspace with the name cms and run its dev command". And this command can be run anywhere within the codebase. One needn't be within the /apps/cms/ directory for the command to work.

But where does the cms identifier come from? In /apps/cms/package.json, you'll see:

{
	"name": "cms",
	// ...
}

This name attribute is what pnpm uses to refer to a workspace.

CMS

The workspace name is cms.

The relevant commands are:

• dev: When running locally
• build: Builds the code for production
• start: Runs the production build

Frontend application

The workspace name is few (short for front-end website).

During development, the only command you need to run is dev.