{"id":29027354,"url":"https://github.com/cahnory/pnpm-monorepo","last_synced_at":"2025-06-26T06:05:29.452Z","repository":{"id":172709337,"uuid":"649613421","full_name":"cahnory/pnpm-monorepo","owner":"cahnory","description":"Template for Monorepo with PNPm, TypeScript, ESLint, Prettier, and TurboRepo.","archived":false,"fork":false,"pushed_at":"2024-05-01T05:26:40.000Z","size":285,"stargazers_count":7,"open_issues_count":2,"forks_count":1,"subscribers_count":1,"default_branch":"main","last_synced_at":"2024-05-01T06:31:24.082Z","etag":null,"topics":["boilerplate","eslint","monorepo","pnpm","prettier","turborepo","typescript","vscode"],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cahnory.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2023-06-05T09:02:50.000Z","updated_at":"2024-05-01T05:26:43.000Z","dependencies_parsed_at":"2023-10-21T10:34:42.394Z","dependency_job_id":"2f6bb958-4255-4783-8e1b-d2f0f5bb8d73","html_url":"https://github.com/cahnory/pnpm-monorepo","commit_stats":null,"previous_names":["cahnory/pnpm-monorepo"],"tags_count":1,"template":true,"template_full_name":null,"purl":"pkg:github/cahnory/pnpm-monorepo","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cahnory%2Fpnpm-monorepo","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cahnory%2Fpnpm-monorepo/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cahnory%2Fpnpm-monorepo/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cahnory%2Fpnpm-monorepo/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cahnory","download_url":"https://codeload.github.com/cahnory/pnpm-monorepo/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cahnory%2Fpnpm-monorepo/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":262010864,"owners_count":23244414,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["boilerplate","eslint","monorepo","pnpm","prettier","turborepo","typescript","vscode"],"created_at":"2025-06-26T06:05:28.749Z","updated_at":"2025-06-26T06:05:29.426Z","avatar_url":"https://github.com/cahnory.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# PNPm Monorepo Boilerplate \u003c!-- omit from toc --\u003e\n\nTemplate for Monorepo with PNPm, TypeScript, ESLint, Prettier, and TurboRepo.\n\n- [1. Initialization](#1-initialization)\n- [2. Package organization: \"apps\" vs \"libs\"](#2-package-organization-apps-vs-libs)\n  - [2.1. Adding a new app](#21-adding-a-new-app)\n  - [2.2. Adding a new lib](#22-adding-a-new-lib)\n- [3. VSCode integration](#3-vscode-integration)\n  - [3.1. Recommended extensions](#31-recommended-extensions)\n  - [3.2. Ensuring consistent VSCode configuration across packages](#32-ensuring-consistent-vscode-configuration-across-packages)\n  - [3.3. Settings](#33-settings)\n    - [3.3.1. Readonly files](#331-readonly-files)\n- [4. Github workflows](#4-github-workflows)\n  - [4.1. Continuous integration](#41-continuous-integration)\n- [5. Scripts](#5-scripts)\n  - [5.1. Package scripts](#51-package-scripts)\n    - [5.1.1. build](#511-build)\n    - [5.1.2. dev](#512-dev)\n    - [5.1.3. lint](#513-lint)\n    - [5.1.4. lint:format](#514-lintformat)\n    - [5.1.5. lint:semantic](#515-lintsemantic)\n    - [5.1.6. lint:types](#516-linttypes)\n    - [5.1.7. lint:fix](#517-lintfix)\n    - [5.1.8. lint:fix:format](#518-lintfixformat)\n    - [5.1.9. lint:fix:semantic](#519-lintfixsemantic)\n    - [5.1.10. test](#5110-test)\n    - [5.1.11. test:unit](#5111-testunit)\n  - [5.2. Root-Level scripts](#52-root-level-scripts)\n    - [5.2.1. build](#521-build)\n    - [5.2.2. commit](#522-commit)\n    - [5.2.3. dev](#523-dev)\n    - [5.2.4. lint](#524-lint)\n    - [5.2.5. lint:format](#525-lintformat)\n    - [5.2.6. lint:semantic](#526-lintsemantic)\n    - [5.2.7. lint:types](#527-linttypes)\n    - [5.2.8. lint:commits](#528-lintcommits)\n    - [5.2.9. lint:rebase](#529-lintrebase)\n    - [5.2.10. lint:fix](#5210-lintfix)\n    - [5.2.11. lint:fix:format](#5211-lintfixformat)\n    - [5.2.12. lint:fix:semantic](#5212-lintfixsemantic)\n    - [5.2.13. test](#5213-test)\n    - [5.2.14. test:unit](#5214-testunit)\n- [6. Troubleshooting](#6-troubleshooting)\n  - [6.1. IDE issues or project malfunctioning? Try `pnpm prepare`!](#61-ide-issues-or-project-malfunctioning-try-pnpm-prepare)\n  - [6.2. Unable to resolve path to module… eslint(\"import/no-unresolved\")](#62-unable-to-resolve-path-to-module-eslintimportno-unresolved)\n\n## 1. Initialization\n\n```bash\ngit clone https://github.com/cahnory/pnpm-monorepo.git \u003cyour-project\u003e\ncd \u003cyour-project\u003e\npnpm install\n```\n\n## 2. Package organization: \"apps\" vs \"libs\"\n\nIn our monorepo, we have two main directories for organizing packages: \"apps\" and \"libs\". It's important to note that the packages located in the \"apps\" directory are not intended to be imported by other packages within the monorepo. These packages typically represent standalone applications or executables.\n\nOn the other hand, the packages residing in the \"libs\" directory are specifically designed to be imported and used by other packages. They provide reusable components, libraries, or modules that facilitate code sharing and maintainability across different parts of the monorepo.\n\n### 2.1. Adding a new app\n\nTo add a new app:\n\n1. duplicate one of the sample app package found in the \"apps\" directory.\n\n2. Rename the duplicated package to your desired new package name.\n\n3. Update the \"name\" property in the package.json file to match the new package name.\n\n   ```json\n   {\n     \"name\": \"@pnpm-monorepo/\u003cnew-app-name\u003e\"\n   }\n   ```\n\n### 2.2. Adding a new lib\n\nTo add a new lib:\n\n1. duplicate one of the sample lib package found in the \"libs\" directory.\n\n2. Rename the duplicated package to your desired new package name.\n\n3. Update the \"name\" property in the package.json file to match the new package name.\n\n   ```json\n   {\n     \"name\": \"@pnpm-monorepo/\u003cnew-package-name\u003e\"\n   }\n   ```\n\n## 3. VSCode integration\n\nThe monorepo includes a VSCode configuration file that optimizes code formatting and enables automatic formatting upon saving files. Additionally, a curated list of recommended extensions is provided, including tools and language-specific extensions essential for code formatting and linting. By utilizing this configuration and installing the recommended extensions, developers can ensure consistent code style and enhance productivity within the monorepo.\n\n### 3.1. Recommended extensions\n\nTo view the recommended extensions for the monorepo, paste **workbench.extensions.action.showRecommendedExtensions** in the command launcher (**F1**). This will open the Recommended Extensions view, where you can see the curated list of extensions. From there, you can easily install any missing extensions.\n\n### 3.2. Ensuring consistent VSCode configuration across packages\n\nEach package contains a symbolic link `./vscode` that points to the root-level `./vscode` directory within the monorepo. This ensures that even if you open an individual package directly in VSCode (as opposed to opening the entire monorepo), you'll have a consistent VSCode configuration. This approach provides a uniform development environment across packages, reducing potential configuration discrepancies.\n\n### 3.3. Settings\n\n#### 3.3.1. Readonly files\n\nSome files are marked as read-only using _files.readonlyInclude_ setting, preventing inadvertent modifications.\n\nBy default, the [configuration](./.vscode/settings.json) includes patterns targeting files and directories commonly generated during development, like \"node_modules\" and \"build\" directories for both apps and libraries:\n\n```json\n  \"files.readonlyInclude\": {\n    \"**/node_modules/**\": true,\n    \"**/apps/*/build/**\": true,\n    \"**/libs/*/build/**\": true\n  }\n```\n\nExtend this list to safeguard additional files as needed.\n\n## 4. Github workflows\n\n### 4.1. Continuous integration\n\nThe [Continuous integration workflow](.github/workflows/ci.yaml) consists of two primary jobs. The first, \"Static Analysis,\" focuses on the static analysis of the code, checking various aspects such as typing, linting, formatting, and commit name consistency. This step ensures code quality independent of the OS and Node.js version.\n\nThe second job, \"Runtime Compatibility,\" tests the project's compatibility across different environments. It runs on multiple Node.js versions on Ubuntu, a common deployment platform, and also includes MacOS and Windows. The goal is to ensure the project operates correctly during installation, building, and testing across various platforms, providing a consistent and reliable development experience for developers.\n\n## 5. Scripts\n\n### 5.1. Package scripts\n\n#### 5.1.1. build\n\nThe _build_ script is used to compile the source code of the package. It generates the necessary output files, such as transpiled JavaScript files or bundled assets. Running this script ensures that the package is built and ready for deployment or usage.\n\n#### 5.1.2. dev\n\nThe _dev_ script is helpful during the development phase. It allows developers to watch the package's source files for changes and automatically triggers a rebuild whenever a file is modified. This feature provides a convenient workflow by keeping the package up to date during development.\n\n#### 5.1.3. lint\n\nThe _lint_ script is responsible for running various linters associated with the package. It divides its functionality into three sub-scripts: lint:format, lint:semantic, and lint:types.\n\n#### 5.1.4. lint:format\n\nThe _lint:format_ script checks that the package's source code adheres to the prettier config defined for the monorepo. It ensures consistent code style throughout the package.\n\n#### 5.1.5. lint:semantic\n\nThe _lint:semantic_ script checks that the package's source code adheres to the eslint rules defined for the monorepo. It enforces best practices, and maintains code quality throughout the package.\n\n#### 5.1.6. lint:types\n\nThe _lint:types_ script verifies that the package's source code is free from TypeScript type errors. It performs static type checking, ensuring type safety within the package. Running this script helps catch potential type-related issues before runtime.\n\n#### 5.1.7. lint:fix\n\nThe _lint:fix_ script attempts to fix all linters issues.\n\n#### 5.1.8. lint:fix:format\n\nThe _lint:fix:format_ script attempts to automatically corrects any formatting/stylistic issues found in the package's source code, ensuring that it adheres to the prettier config defined for the monorepo.\n\n#### 5.1.9. lint:fix:semantic\n\nThe _lint:fix:semantic_ script attempts to automatically fixes any code issues that do not adhere to the eslint rules defined for the monorepo.\n\n#### 5.1.10. test\n\nThe _test_ script is responsible for running various tests associated with the package. It validates the functionality and quality of the package.\n\n#### 5.1.11. test:unit\n\nThe _test:unit_ script runs the package's unit tests. It validates the behavior of individual components, functions, or modules within the package. This script ensures that the package's internal units are functioning as expected.\n\n### 5.2. Root-Level scripts\n\nThe monorepo also includes root-level scripts with similar functionality as their package-level counterparts. The key distinction is that these scripts can be executed across all packages within the monorepo simultaneously, providing a unified and efficient workflow. Running the root-level scripts allows you to perform the respective actions (build, dev, test) on multiple packages within the monorepo in a single operation. This saves time and ensures consistency across the entire codebase.\n\n#### 5.2.1. build\n\nRun the _build_ script for all packages within the monorepo.\n\n#### 5.2.2. commit\n\nCommt using [commitizen](https://commitizen.github.io/cz-cli/). Get instant feedback on your commit message formatting and be prompted for required fields\n\n#### 5.2.3. dev\n\nRun the _dev_ script for all packages within the monorepo.\n\n#### 5.2.4. lint\n\nRun the _lint_ script on all packages within the monorepo followed by the root scripts lint:commits and lint:rebase.\n\n#### 5.2.5. lint:format\n\nRun the _lint:format_ script for all packages within the monorepo.\n\n#### 5.2.6. lint:semantic\n\nRun the _lint:semantic_ script for all packages within the monorepo.\n\n#### 5.2.7. lint:types\n\nRun the _lint:types_ script for all packages within the monorepo.\n\n#### 5.2.8. lint:commits\n\nThe \"lint:commits\" script verifies the commit messages of the commits added by the current branch using the commitlint library. It performs linting or checks against predefined rules, specified in the commitlint configuration, to ensure that the commit messages follow specific guidelines or standards. This helps maintain consistency and clarity in the commit history of the project.\n\nYou can learn more about commitlint by visiting the [official commitlint documentation](https://commitlint.js.org/).\n\n#### 5.2.9. lint:rebase\n\nThe _test:rebase_ script examines whether a rebase with the remote default branch is necessary. It analyzes the current branch's changes and compares them with the default branch in the remote repository. This check helps identify if the current branch is outdated or needs to be updated to incorporate the latest changes from the default branch. Performing the necessary rebase ensures that the branch remains up to date and avoids potential conflicts during future merges or pull requests.\n\n#### 5.2.10. lint:fix\n\nRun the _lint:fix_ script on all packages within the monorepo.\n\n#### 5.2.11. lint:fix:format\n\nRun the _lint:fix:format_ script for all packages within the monorepo.\n\n#### 5.2.12. lint:fix:semantic\n\nRun the _lint:fix:semantic_ script for all packages within the monorepo.\n\n#### 5.2.13. test\n\nRun the _test_ script on all packages within the monorepo.\n\n#### 5.2.14. test:unit\n\nRun the _test:unit_ script for all packages within the monorepo.\n\n## 6. Troubleshooting\n\n### 6.1. IDE issues or project malfunctioning? Try `pnpm prepare`!\n\nIf you encounter errors in your IDE or if your project is not functioning properly, it is likely that an event such as a branch change, stash application, pull, or repository reset has occurred. In such cases, the recommended first step is to execute the pnpm prepare command:\n\n```bash\npnpm run prepare\n```\n\nThe pnpm prepare command is designed to reinstall project dependencies and perform any necessary build or configuration tasks. This ensures that your project is in sync with any potential modifications that have taken place.\n\n### 6.2. Unable to resolve path to module… eslint(\"import/no-unresolved\")\n\nWhen trying to import a package from the repository, if you encounter the error message:\n\n\u003e Unable to resolve path to module \"@pnpm-monorepo/\\\u003cmodule-name\\\u003e\". eslint(\"import/no-unresolved\")\n\nit is an indication that the package may need to be built or rebuilt. Execute the pnpm prepare command:\n\n```bash\npnpm run prepare\n```\n\nThis could happen because an event such as a branch change, stash application, pull, or repository reset has occurred or if you're making modification to source files without runing the dev script.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcahnory%2Fpnpm-monorepo","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcahnory%2Fpnpm-monorepo","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcahnory%2Fpnpm-monorepo/lists"}