create-nuxt-app

create-nuxt-app copied to clipboard

This PR adds Dockerfile and docker-compose.yml as devOps option 🐳

Of course, making a CI/CD for each project is time consuming and different for each project, and therefore requires a Docker image with a different structure, but in small projects having a code sample can be very helpful. You should also spend more time on related documentation and introduce different Docker image structures so that people can create their own Docker image as needed.

2 years is a pretty long time, is there any plan to introduce a first iteration of the Docker image variant yet? I'd like to eventually integrate new improvements or workarounds, but it's difficult to open PRs if nothing has been merged yet. Can we get any information about what is currently being worked on? It would be great if we had a documentation for various use-cases, or even better, if the Dockerfile was self-documented with available next steps after providing users with multiple generation options. For example, dev mode or build vs. generate may differ (and so does SSR), and we need workarounds like envsubst if we want to pass environment variables to nginx. Kubernetes tools could be also added in the following iterations, and so could tools like podman to become more inclusive.

• It's non-trivial to create a multi-platform baseline that new projects can easily reuse, and there are plenty of additional DX improvements available, for example adding common docker use-cases as npm scripts, e.g. stop & rm to clean the containers (npm i -D cash-true and adding "docker:clean": "echo Cleaning up Docker containers && (docker stop image-name || true) && (docker rm image-name || true)"), agreeing on optimal cache usage (--no-cache), parametrizing env using cross-env-shell with workarounds (e.g. cross-env-shell docker run --name project_name -v '\\\"$INIT_CWD:/usr/src/app\\\"'), referring to build image using $npm_package_version, using separate image name for dev mode, pipeline to push the image, etc.

The pros and cons of specific implementations (e.g. base docker images and their versions) could be listed somewhere as a source of truth to make it easier to suggest changes once the dependent technologies further evolve, so that users aren't stuck with ad-hoc decisions in their projects if they prefer zero-configuration.

---

Also related to Nuxt 3 docs:

• https://github.com/nuxt/framework/pull/3331