Should you run
npm run build on your development machine and commit everything to Git or should you commit your app without those files and run
npm run build on your production server? Here are the pros and cons of those two approaches:
npm run build on Development and Committing to Git
- Consistency: Ensures that the build is consistent across environments since you’re deploying the exact same files that were tested in development.
- Faster Deployment: Reduces the deployment time as the build step is already done.
- Simplicity: Simplifies the production deployment process, especially if your production environment has limitations.
- Repository Size: Increases the size of your Git repository, as built files, especially from front-end frameworks, can be quite large.
- Merge Conflicts: Can lead to potential merge conflicts with built files, especially if multiple developers are working on the project.
- Outdated Artifacts: There’s a risk of deploying outdated artifacts if developers forget to rebuild after making changes.
npm run build on Production
- Clean Repository: Keeps the repository clean as you only commit source files.
- Up-to-Date Builds: Ensures that the latest source is always built for production, reducing the risk of deploying outdated code.
- Environment Specific Builds: Allows for creating environment-specific builds if needed (e.g., different API endpoints, feature toggles).
- Longer Deployment Time: Increases deployment time as the build process is part of the deployment.
- Potential for Build Failures: If there are issues in the build process, they will only be caught during deployment, which can be risky.
- Dependency on Build Tools in Production: Requires that your production environment has the necessary build tools and configurations.
Alternative: Use Continuous Integration (CI)
Automate the build process using a CI/CD pipeline. This way, you can run tests and build in a controlled environment, and then deploy the artifacts to production. This combines the benefits of both approaches.