You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 21, 2024. It is now read-only.
You are better off building a Docker image from scratch, see below how. 🤓
6
6
7
-
# Node.js frontend development with Chrome Headless tests
7
+
There are more details about the deprecation at the end.
8
8
9
-
This Docker image simplifies the process of creating a full Node.js environment for frontend development with multistage building.
10
-
11
-
It includes all the dependencies for Puppeteer, so you can just `npm install puppeteer` and it should work.
12
-
13
-
It also includes a default Nginx configuration for your frontend application, so in multi-stage Docker builds you can just copy it to an Ngnix "stage" and have an always freshly compiled production ready frontend Docker image for deployment.
14
-
15
-
It is derivated from this article I wrote:
16
-
17
-
> Angular in Docker with Nginx, supporting configurations / environments, built with multi-stage Docker builds and testing with Chrome Headless
18
-
19
-
[in Medium](https://medium.com/@tiangolo/angular-in-docker-with-nginx-supporting-environments-built-with-multi-stage-docker-builds-bb9f1724e984), and [in GitHub](https://github.com/tiangolo/medium-posts/tree/master/angular-in-docker)
20
-
21
-
## How to use
9
+
## Build a Frontend Docker Image
22
10
23
11
### Previous steps
24
12
25
-
* Create your frontend Node.js based code (Angular, React, Vue.js).
13
+
* Create your frontend Node.js based code (React, etc).
26
14
27
15
* Create a file `.dockerignore` (similar to `.gitignore`) and include in it:
28
16
@@ -32,19 +20,19 @@ node_modules
32
20
33
21
...to avoid copying your `node_modules` to Docker, making things unnecessarily slower.
34
22
35
-
* If you want to integrate testing as part of your frontend build inside your Docker image building process (using Chrome Headless via Puppeteer), install Puppeteer locally, so that you can test it locally too and to have it in your development dependencies in your `package.json`:
23
+
* If you want to integrate testing as part of your frontend build inside your Docker image building process, install any dependencies you might need, for example Playwright, so that you can test it locally too and to have it in your development dependencies in your `package.json`:
36
24
37
25
```bash
38
-
npm install --save-dev puppeteer
26
+
npm init playwright@latest
39
27
```
40
28
41
29
### Dockerfile
42
30
43
-
* Create a file `Dockerfile`based on this image and name the stage `build-stage`, for building:
31
+
* Create a file `Dockerfile`for building and name the stage `build-stage`:
44
32
45
33
```Dockerfile
46
34
# Stage 0, "build-stage", based on Node.js, to build and compile the frontend
47
-
FROMtiangolo/node-frontend:10 as build-stage
35
+
FROM node:latest as build-stage
48
36
49
37
...
50
38
@@ -62,7 +50,7 @@ COPY package*.json /app/
62
50
...
63
51
```
64
52
65
-
...just the `package*.json` files to install all the dependencies once and let Docker use the cache for the next builds. Instead of installing everything after every change in your source code.
53
+
...copy just the `package*.json` files to install all the dependencies once and let Docker use the cache for the next builds. By doing this before copying the whole app code, Docker will be able to use the cache and you won't have to wait for Docker to install with `npm install`every time you change the code.
66
54
67
55
* Install `npm` packages inside your `Dockerfile`:
68
56
@@ -74,8 +62,7 @@ RUN npm install
74
62
...
75
63
```
76
64
77
-
* Copy your source code, it can be TypeScript files, `.vue` or React with JSX, it will be compiled inside Docker:
78
-
65
+
* Copy your source code to the Docker image:
79
66
80
67
```Dockerfile
81
68
...
@@ -85,28 +72,28 @@ COPY ./ /app/
85
72
...
86
73
```
87
74
88
-
* If you have integrated testing with Chrome Headless using Puppeteer, this image comes with all the dependencies for Puppeteer, so, after installing your dependencies (including `puppeteer` itself), you can just run it. E.g.:
75
+
* If you need to pass build arguments, create a default `ARG` to be used at build time:
89
76
90
77
```Dockerfile
91
78
...
92
79
93
-
RUN npm run test -- --browsers ChromeHeadlessNoSandbox --watch=false
80
+
ARG VITE_API_URL=${VITE_API_URL}
94
81
95
82
...
96
83
```
97
84
98
-
...if your tests didn't pass, they will throw an error and your build will stop. So, you will never ship a "broken" frontend Docker image to production.
99
-
100
-
* If you need to pass buildtime arguments, for example in Angular, for `--configuration`s, create a default `ARG` to be used at build time:
85
+
* If you have integrated testing, you can run your tests now:
101
86
102
87
```Dockerfile
103
88
...
104
89
105
-
ARG configuration=production
90
+
RUN npm run test
106
91
107
92
...
108
93
```
109
94
95
+
...if your tests didn't pass, they will throw an error and your build will stop. So, you will never ship a "broken" frontend Docker image to production.
96
+
110
97
* Build your source frontend app as you normally would, with `npm`:
111
98
112
99
```Dockerfile
@@ -117,25 +104,15 @@ RUN npm run build
117
104
...
118
105
```
119
106
120
-
* If you need to pass build time arguments (for example in Angular), modify the previous instruction using the previously declared `ARG`, e.g.:
121
-
122
-
```Dockerfile
123
-
...
124
-
125
-
RUN npm run build -- --output-path=./dist/out --configuration $configuration
126
-
127
-
...
128
-
```
129
-
130
-
...after that, you would have a fresh build of your frontend app code inside a Docker container. But if you are serving frontend (static files) you could serve them with a high performance server as Nginx, and have a leaner Docker image without all the Node.js code.
107
+
...after that, you would have a fresh build of your frontend app code inside a Docker image. But if you are serving frontend (static files) you could serve them with a high performance server as Nginx, and have a leaner Docker image without all the Node.js code.
131
108
132
109
* Create a new "stage" (just as if it was another Docker image in the same file) based on Nginx:
133
110
134
111
```Dockerfile
135
112
...
136
113
137
114
# Stage 1, based on Nginx, to have only the compiled app, ready for production with Nginx
... make sure you change `/app/dist/out/` to the directory inside `/app/` that contains your compiled frontend code.
130
+
* Create a file `nginx.conf` with:
154
131
155
-
* This image also contains a default Nginx configuration so that you don't have to provide one. By default it routes everything to your frontend app (to your `index.html`), so that you can use "HTML5" full URLs and they will always work, even if your users type them directly in the browser. Make your Docker image copy that default configuration from the previous stage to Nginx's configurations directory:
132
+
```Nginx
133
+
server {
134
+
listen 80;
135
+
136
+
location / {
137
+
root /usr/share/nginx/html;
138
+
index index.html index.htm;
139
+
try_files $uri /index.html =404;
140
+
}
141
+
}
142
+
```
143
+
144
+
* This configuration routes everything to your frontend app (to your `index.html`), so that you can use full URLs and they will always work, even if your users type them directly in the browser. Make your Docker image copy that configuration to Nginx's configurations directory:
...If you had tests and added above, they will be run. Your app will be compiled and you will end up with a lean high performance Nginx server with your fresh compiled app. Ready for production.
191
+
...If you had tests and added them above, they will be run. Your app will be compiled and you will end up with a lean high performance Nginx server with your fresh compiled app. Ready for production.
203
192
204
-
* If you need to pass build time arguments (like for Angular `--configuration`s), for example if you have a "staging" environment, you can pass them like:
193
+
* If you need to pass build time arguments, for example if you have a "staging" environment, you can pass them like:
@@ -225,11 +214,11 @@ docker run -p 80:80 my-frontend-project:prod
225
214
npm run start
226
215
```
227
216
228
-
...use it.
217
+
...use it.
229
218
230
219
It's faster and simpler to develop locally. But once you think you got it, build your Docker image and try it. You will see how it looks in the full production environment.
231
220
232
-
* If you want to have Chrome Headless tests, run them locally first, as you normally would (Karma, Jasmine, Jest, etc). Using the live normal browser. Make sure you have all the configurations right. Then install Puppeteer locally and make sure it runs locally (with local Headless Chrome). Once you know it is running locally, you can add that to your `Dockerfile` and have "continuous integration" and "continuous building"... and if you want add "continuous deployment". But first make it run locally, it's easier to debug only one step at a time.
221
+
* If you want to have tests using a (maybe headless) browser, run them locally first, as you normally would. Using the live normal browser. Make sure you have all the configurations right. Once you know it is running locally, you can add that to your `Dockerfile` and have "continuous integration" and "continuous building"... and if you want, add "continuous deployment". But first make it run locally, it's easier to debug only one step at a time.
233
222
234
223
* Have fun.
235
224
@@ -284,6 +273,24 @@ By making Nginx simply respond with 404 errors when requested for `/docs`, you a
284
273
285
274
And because you have a load balancer on top, redirecting requests to `/docs` to the correct service, Nginx would never actually return that 404. Only in the case of a failure, or during development.
286
275
276
+
## Deprecated Image
277
+
278
+
This used to be a Docker image to simplify the process of creating a full Node.js environment for frontend development with multistage building.
279
+
280
+
It included all the dependencies for Puppeteer, so you could just `npm install puppeteer` and it should work.
281
+
282
+
It also included a default Nginx configuration for your frontend application, with the same content above, so in multi-stage Docker builds you could copy it to an Nginx "stage".
283
+
284
+
It is derived from this article I wrote:
285
+
286
+
> Angular in Docker with Nginx, supporting configurations / environments, built with multi-stage Docker builds and testing with Chrome Headless
287
+
288
+
[in Medium](https://medium.com/@tiangolo/angular-in-docker-with-nginx-supporting-environments-built-with-multi-stage-docker-builds-bb9f1724e984), and [in GitHub](https://github.com/tiangolo/medium-posts/tree/master/angular-in-docker)
289
+
290
+
As copying the `nginx.conf` file to the `Dockerfile` is not that much work, and the dependencies for Puppeteer are probably no longer relevant as Playwright is in many cases a better option, it doesn't make sense to keep supporting this Docker image, and it doesn't make sense for you to use it.
291
+
292
+
You are better off following the instructions above. 🤓
0 commit comments