long fossil
Hello I am implementing a Dockerfile in my Astro project and when building the image it has been failing giving me this error message, I have been able to solve it as indicated in this issue but I would like to know if this is an error only mine or if it also happens to other people and if there would be another way to solve it other than as indicated in the issue.
package.json{
"name": "",
"type": "module",
"version": "0.0.1",
"scripts": {
"dev": "astro dev",
"start": "astro dev",
"build": "astro build",
"preview": "astro preview",
"astro": "astro",
"prepare": "husky"
},
"dependencies": {
"@astrojs/node": "8.2.5",
"@astrojs/sitemap": "3.1.5",
"@astrojs/ts-plugin": "1.8.0",
"astro": "4.9.1",
"astro-capo": "0.0.1",
"photoswipe": "5.4.3",
"satori": "0.10.13",
"satori-html": "0.3.2",
"sharp": "0.33.4"
},
"devDependencies": {
"@typescript-eslint/eslint-plugin": "7.9.0",
"@typescript-eslint/parser": "7.9.0",
"eslint": "8.57.0",
"eslint-config-prettier": "9.1.0",
"eslint-config-standard": "17.1.0",
"eslint-plugin-astro": "1.1.2",
"eslint-plugin-import": "2.29.1",
"eslint-plugin-jsx-a11y": "6.8.0",
"eslint-plugin-n": "16.6.2",
"eslint-plugin-promise": "6.1.1",
"husky": "9.0.11",
"lint-staged": "15.2.2",
"prettier": "3.2.5",
"prettier-plugin-astro": "0.13.0",
"typescript": "^5.4.5"
},
"lint-staged": {
"src/**/*.{js,astro}": [
"eslint --fix"
],
"src/**/*.{js,astro,html,css,md}": [
"prettier --write"
]
},
"optionalDependencies": {
"@rollup/rollup-linux-x64-gnu": "4.9.5"
}
}
DockerfileFROM node:20.11.0 AS base
WORKDIR /app
# By copying only the package.json and package-lock.json here, we ensure that the following `-deps` steps are independent of the source code.
# Therefore, the `-deps` steps will be skipped if only the source code changes.
COPY package.json package-lock.json ./
FROM base AS prod-deps
RUN npm install --omit=dev --frozen-lockfile --ignore-scripts
FROM base AS build-deps
RUN npm install --frozen-lockfile
FROM build-deps AS build
COPY . .
RUN npm run build
FROM base AS runtime
COPY --from=prod-deps /app/node_modules ./node_modules
COPY --from=build /app/dist ./dist
ENV HOST=0.0.0.0
ENV PORT=4321
EXPOSE 4321
CMD node ./dist/server/entry.mjs
young zephyr
you likely copied your local node_modules and broke the previous installation by the really bad example of COPY . .
add node modules to your .dockerignore
FYI @quiet meadow
acoustic snow
im coming across the same issue.
long fossil
add node modules to your `.dockerignore`
this is the docker ignore that I already had created:
.DS_Store
node_modules
dist
hmm, another thing could be is the --ignore-scripts
some packages require the scripts to install their platform specific versions
long fossil
i added that so that when installing the prod dependencies it won't fail since husky adds the prepare script
the only difference between it failing or not is adding these lines in the package.json as discussed in that issue:
"optionalDependencies": {
"@rollup/rollup-linux-x64-gnu": "4.9.5"
}
one other thing to look out is the --frozen-lockfile
with that you need to generate your lockfile in the target environment to it to be good
like a mac or windows lockfile will not always work in a linux image
nice find on the workaround!
quiet meadow
you likely copied your local `node_modules` and broke the previous installation ...
I never use "COPY . ." and I do not recommend it 😉
especially where you use the folder for local and docker
young zephyr
that is quite a different take compre to 3 weeks ago, unless you are not the same person on github
quiet meadow
no, the thing is Astro cannot easily cover topics beyond Astro dev, this is mainly Docker know how, it's a big challenge to try to cover all other dev frameworks catches inside Astro doc. For this case in particular it would have saved troubles I give you that. I'm still not insisting on making Astro doc responsible of documenting such catches, as they are endless.
Also, the thing is, that PR had a specific suggestion which was not wrong and acceptable, if someone (cough cough) makes an improvement doc PR I'd definitely upvote it 🙂
young zephyr
I still do not see why would anyone hold back their knowledge to showcase an objectively better example just because the context's focus is not exactly to do the best practice...
These kind of issues will happen because of such negligent approach.
quiet meadow
I understand your perspective. From the perspective of the "other" PR owner, he wanted to fix something and did it, so it is not fair to block the PR and ask for more, such improvements are welcome on a separate PR, otherwise it's hard to get improvements through if not step by step. No one really denied the advantage you suggested. So would you like to take a new PR in charge, I'll help !
glad fern
I still do not see why would anyone hold back their knowledge to showcase an obj...
Please can we try and stick to a more positive tone when discussing existing resources and not blaming other members of the community.
Nobody is acting maliciously and we are all striving to make Astro as good as it possibly can be. If things can be improved, so be it, but please keep criticism positive and constructive
young zephyr
Very well, then I shall leave these topics for other members in the future as I do not wish that my opinion and expectation towards professionals are miss-interpreted as blaming.
long fossil
I have tried deleting --frozen-lockfile but it keeps failing
long fossil
It also fails if I try to build inside a wsl.
quiet meadow
It also fails if I try to build inside a wsl.
as discussed above, can you try to remove the "copy . ." and create new copies of all needed files e.g. using ../*.js,... but make sure nothing can be copied from node_modules keeping the docker ignore is also good, that would be more work but a proper solution, also make sure to delete the old image and build a new one.