Si tuviera que empezar un nuevo proyecto de NestJS usaría esto!

Summary

The video script discusses the creator's personal journey and preferences when starting new projects using the Nest.js framework. Initially, they followed the standard approach of installing Nest globally and using its CLI to create new projects. However, they have since moved away from this due to various reasons, including the need for customization for production environments like Kubernetes, dissatisfaction with the default project structure, and the desire for a more organized approach to testing and configuration files. The creator shares their current practices, which involve using a custom template that is Docker-ready, includes Husky for Git hooks, and follows specific coding conventions enforced by conventional commits. They also mention the integration of a health check endpoint and the option to configure the logging level. The template is designed to be adaptable to different project needs and is continuously evolving with the creator's learning process. The video concludes with an invitation for viewers to use, customize, and share the template to foster community growth and knowledge sharing.

Takeaways

• 📦 The speaker discusses the initial steps of setting up a new project using NestJS, including installing NestJS globally and using the `nest new project-name` command.
• 🚀 The default NestJS project template is criticized for not being optimized for speed or production readiness, such as for environments like Kubernetes.
• 🧩 The organization of unit tests within the same directory as the TypeScript source files is seen as a downside, as it mixes testing with source code.
• 📝 There is dissatisfaction with the configuration of testing being included in the `package.json`, which could be separated into a dedicated configuration file.
• ⚙️ Mention of alternative TypeScript compilers like SWC, which is faster than the native `tsc` compiler that comes with NestJS.
• 🚄 A preference for using a different HTTP framework, such as Fastify, over the default Express, which is slower but more widely adopted due to familiarity.
• 🌱 The speaker has created a personal template for new NestJS projects that includes Docker, Husky for git hooks, and conventional commits for commit message formatting.
• 🛠️ The template is designed to be production-ready with best practices for Docker, including small image sizes and minimal necessary files.
• 📓 The separation of unit tests into their own directory is highlighted as an improvement over the default NestJS template.
• 🔍 The template includes a configuration for code coverage, specifying a minimum threshold and which files to exclude from coverage checks.
• 🌐 The project is set up with considerations for Kubernetes environments, such as health check routes for service monitoring.
• ✅ The use of a custom NestJS template allows for personal preferences and project-specific needs to be integrated, making the development process more efficient and enjoyable for the creator.

Q & A

What is the first step recommended in the script when starting a new project from scratch using NestJS?

The first step is to install the Nest CLI globally and then use the `nest new project-name` command to create a new project.

Why has the speaker stopped using the default command provided by the NestJS framework?

The speaker has stopped using the default command because they found the default project setup not optimized for production environments, particularly in terms of performance and security configurations.

What issue does the speaker have with the default testing setup in the NestJS template?

The speaker does not like that the unit tests are placed at the same level as the TypeScript source files, which leads to a mixing of testing code with the source code.

What is the speaker's preference regarding the separation of testing code and source code?

The speaker prefers to have the testing code and source code separated, allowing for better organization and the ability to include additional testing-related files and configurations without mixing them with the application code.

Why does the speaker find the configuration of testing in the package.json to be problematic?

The speaker finds it problematic because it clumps all the testing configuration together, which can lead to a large file that is not easily maintained, and it mixes project dependencies with testing configurations.

What alternative to the native TypeScript compiler (tsc) is mentioned in the script?

The alternative mentioned is SWC, which is said to be significantly faster than the native TypeScript compiler and fully compatible with NestJS projects.

What is the speaker's opinion on the default HTTP framework used by NestJS?

The speaker believes that while NestJS defaults to using Express, it is not the most performant option. They mention Fastify as a faster alternative that is even recommended by the NestJS documentation.

What does the speaker suggest regarding the choice of HTTP framework when starting a new NestJS project?

The speaker suggests that NestJS should provide an option when starting a new project to choose between the native (but slower) TypeScript compiler and a faster alternative like SWC, allowing developers to decide based on their performance needs.

What is the speaker's approach to creating a new project template for NestJS?

The speaker has created a custom template that includes Dockerization, Husky for pre-commit checks, conventional commits, and a configurable logger module. It also separates unit tests into their own folder and allows for customization according to personal or project needs.

How does the speaker's custom template address the issue of testing code organization?

The custom template separates unit tests into their own folder, mirroring the structure of the source code folder but dedicated solely to tests, thus keeping the testing code separate from the source code.

What feature does the speaker include in the template to ensure code quality and consistency?

The speaker includes Husky for pre-commit hooks to run linting and tests automatically, and conventional commits to enforce a commit message convention, ensuring code quality and consistency.

What is the speaker's stance on the inclusion of an architecture in the custom template?

The speaker's custom template does not include a pre-defined architecture, allowing developers to choose and implement the architecture that best suits their project, whether it be hexagonal, three-tier, MVC, or any other.