-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
76c4bcf
commit 7f04b31
Showing
9 changed files
with
205 additions
and
157 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| # Standards | ||
|
|
||
| In this section, all the standards and conventions adopted to standardize the applications developed in Devmy are summarized. | ||
| Implementing uniform standards is crucial for ensuring consistency, maintainability, and code quality across all projects. | ||
| These principles not only facilitate collaboration among team members but also ensure that applications are easily understandable and scalable over time. | ||
| Following these guidelines helps reduce the risk of errors and improve development efficiency, allowing teams to focus | ||
| on innovation and problem-solving rather than managing discrepancies in the code. | ||
|
|
||
| ## Big Picture | ||
|
|
||
|  | ||
|
|
||
| The main idea is to create a cohesive and easy-to-use structure for developers, favoring centralization rather than scattering resources. | ||
| The standardized commands in the package | ||
| (`dev`, `build`, `start`, `test`, `e2e`, `lint`, `release`) are not just predefined scripts; they represent the only scripts necessary | ||
| for any application. We should add new scripts only in cases of extreme necessity. | ||
| If something requires more complex management, it needs to be analyzed and integrated into an npm (or pub) script. | ||
|
|
||
| For example, for integrating [Cypress](https://www.npmjs.com/package/cypress), instead of creating new scripts in the package, we developed | ||
| [@devmy/cypress-runner](https://www.npmjs.com/package/@devmy/cypress-runner) so that it can be used by everyone without | ||
| adding complexity to the package commands, thus maintaining a high developer experience. | ||
| The same principle applies to the [dotenv Vault](https://www.dotenv.org/docs/security/env-vault) file in the project root | ||
| with prefix filtering: it is designed to be shared with all applications, centralizing configurations in a single point | ||
| without duplicating them in [Gitlab](https://www.gitlab.com) environment variables or other pipeline systems. | ||
|
|
||
| Regarding configurations, instead of replicating information in [Gitlab CI/CD Variables](https://docs.gitlab.com/ee/ci/variables), we created | ||
| [@devmy/dotenv2shell](https://www.npmjs.com/package/@devmy/dotenv2shell) to load [Dotenv Vault](https://www.dotenv.org/docs/security/env-vault) environments into the execution | ||
| shell of GitLab pipelines. This approach enhances the developer experience and promotes centralization of configurations. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,10 @@ | ||
| ### Application Port | ||
|
|
||
| Regarding the ports for launching various applications, we have standardized them to centralize and unify the setup. This approach eliminates the frustration of remembering the specific port for the frontend application built with a particular framework in a given project. The standardized ports are: | ||
|
|
||
| | target | port | localhost | | ||
| |----------|------|----------------| | ||
| | Frontend | 4000 | localhost:4000 | | ||
| | Backend | 3000 | localhost:3000 | | ||
|
|
||
| This standardization ensures a cohesive development environment and simplifies the process for developers. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| # Configuration | ||
|
|
||
| We use [Dotenv Vault](https://www.dotenv.org/docs/security/env-vault) created at the root of the monorepo. | ||
| Each application within the monorepo has access only to the parameters relevant to it, utilizing prefix filtering | ||
| tools such as [Vite env-and-mode](https://vitejs.dev/guide/env-and-mode#env-files), [Webpack with @dotenv-run/webpack](https://www.npmjs.com/package/@dotenv-run/webpack), | ||
| [Jest with @dotenv-run/jest](https://www.npmjs.com/package/@dotenv-run/jest), [Angular with @ngx-env/builder](https://www.npmjs.com/package/@ngx-env/builder) and | ||
| [dotenv-run](https://dotenv.run). | ||
|
|
||
| ## Benefits of Centralized Configuration | ||
|
|
||
| - **Single Management Point**: Centralized management of all configurations for all applications. | ||
| - **Enhanced Security**: Reduces the risk of sharing sensitive information between different applications due to prefix filtering. | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| # Monorepo - NX | ||
|
|
||
| Each Devmy project is configured as an NX monorepo, allowing centralized management of all related applications and leveraging NX's caching mechanisms for builds. | ||
|
|
||
| ## Benefits of the NX Monorepo | ||
|
|
||
| - **Centralized Management**: Manage all applications in a single repository. | ||
| - **Build Cache**: Uses NX cache to optimize builds, reducing compilation times. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,23 @@ | ||
| # Standardized Package Commands | ||
|
|
||
| The package manager is standardized with the following commands: | ||
|
|
||
| - `dev`: Launches the monorepo (or single application) in development mode, activating hot-reload. NX builds the libraries that the single project depends on. | ||
| - `build`: Executes the production build of the entire monorepo (or single application). NX builds the libraries that the single project depends on. | ||
| - `start`: Starts the applications compiled with the production build (or single application). NX runs the build for the single project and all its dependencies. | ||
| - `lint`: Performs lint operations on the project or the monorepo. | ||
| - `lint:fix`: Performs lint fixes on the project. | ||
| - `test`: Runs tests on the project or the monorepo. | ||
| - `test:headless`: Runs tests in headless mode, useful for pipelines. | ||
| - `e2e`: Runs end-to-end tests. | ||
| - `e2e:headless`: Runs end-to-end tests in headless mode, useful for pipelines. | ||
|
|
||
| ## Design Pattern Composite | ||
|
|
||
| By adopting the same interface for the package in sub-projects through NX, we implement the Composite Design Pattern. This pattern allows us to treat individual objects and compositions of objects uniformly through a common interface. | ||
|
|
||
| ## Benefits of the Composite Design Pattern | ||
|
|
||
| - **Uniform Access**: Simplifies the development and maintenance process by reducing dependency on specific implementation details. | ||
| - **Modularity and Reusability**: Promotes modularity and code reusability by allowing individual objects and compositions to be treated the same way. | ||
| - **Agnostic Pipelines**: Allows pipelines to be written in a way that is completely agnostic of the project they are working on. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,27 @@ | ||
| # Package Manager - Corepack + PNPM | ||
|
|
||
| Choosing the right package manager is crucial for ensuring efficient dependency management in our project, facilitating the work of developers, and optimizing the overall performance of the application. After careful consideration, we have decided to adopt **Corepack** alongside **PNPM** for the following reasons: | ||
|
|
||
| - **Automated Version Management**: | ||
| - **Corepack** simplifies the management of package manager versions, ensuring that developers always use the correct versions of PNPM (or other supported managers) without having to manually configure each environment. | ||
| - This automation helps avoid version conflicts and improves the reliability of builds. | ||
|
|
||
| - **Optimized Performance**: | ||
| - **PNPM** is designed to be highly performant, reducing installation times for dependencies through the use of an advanced caching system. | ||
| - Compared to other package managers, PNPM employs a global store approach for dependencies, allowing packages to be shared across projects, minimizing the time and space required for installations. | ||
|
|
||
| - **Efficient Disk Space Usage**: | ||
| - PNPM's strategy of linking dependencies rather than duplicating them significantly reduces disk space usage, making the installation process leaner and less burdensome on the system. | ||
|
|
||
| - **Stringent Package Policy**: | ||
| - PNPM enforces a strict policy regarding which packages the application can access, enhancing security and ensuring that only declared dependencies are included in the project. | ||
| - This approach minimizes the risk of vulnerabilities and conflicts, improving the overall stability of the application. | ||
|
|
||
| In summary, the combination of **Corepack** and **PNPM** allows us to optimize dependency management, improve performance, and ensure greater security in our development environment. These choices reflect our commitment to maintaining an effective and modern workflow in line with industry best practices. | ||
|
|
||
| ## Goodbye NVM | ||
| With the adoption of `Corepack` and `PNPM`, there is no longer a need to use `NVM` to manage Node versions, further simplifying the setup process and improving workflow efficiency. | ||
|
|
||
| ## Sources | ||
| - [Corepack](https://nodejs.org/api/corepack.html) | ||
| - [PNPM](https://pnpm.io/) |
Oops, something went wrong.