Attempted to load SWC binary
Unanswered
Flammulated Owl posted this in #help-forum
Flammulated OwlOP
8.579 > freshicipes@0.1.0 build
8.579 > next build
8.579
9.273 Attention: Next.js now collects completely anonymous telemetry regarding usage.
9.273 This information is used to shape Next.js' roadmap and prioritize features.
9.273 You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
9.273 https://nextjs.org/telemetry
9.273
9.394 â–² Next.js 14.1.4
9.394 - Environments: .env
9.394
9.526 Creating an optimized production build ...
10.16 âš Attempted to load @next/swc-linux-x64-gnu, but it was not installed
10.16 âš Attempted to load @next/swc-linux-x64-musl, but an error occurred: libc.musl-x86_64.so.1: cannot open shared object file: No such file or directory
10.43 ⨯ Failed to load SWC binary for linux/x64, see more info here: https://nextjs.org/docs/messages/failed-loading-swcI went on the link that says "npm i --force" didn't work and
swcMinify: false neither :(can someone help? This a Docker build
24 Replies
Flammulated OwlOP
# Install dependencies only when needed
FROM node:18-alpine AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package.json ./
RUN npm i -g npm@latest && npm install --frozen-lockfile --force
# Rebuild the source code only when needed
FROM node:18 AS builder
WORKDIR /app
COPY . .
COPY .env* ./
COPY --from=deps /app/node_modules ./node_modules
RUN npx prisma generate
RUN npm i -g npm@latest && npm run build && npm install --omit=dev --ignore-scripts --prefer-offline --force
# Production image, copy all the files and run next
FROM node:18 AS runner
WORKDIR /app
ENV NODE_ENV production
# You only need to copy next.config.mjs if you are NOT using the default configuration
COPY .env* ./
COPY --from=builder /app/next.config.mjs ./
COPY --from=builder /app/public ./public
COPY --from=builder --chown=root:root /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
RUN chown -R root:root node_modules/@prisma
COPY prisma ./prisma
EXPOSE 3000
ENV PORT 3000
# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Uncomment the following line in case you want to disable telemetry.
ENV NEXT_TELEMETRY_DISABLED 1
CMD npx prisma migrate deploy && node_modules/.bin/next start -p 3000This is my docker file
Asian black bear
@Flammulated Owl This is kind of a mess, you are trying to download the node_modules in Alpine but then use them in Debian. Since SWC is a binary component whatever you are downloading in Alpine is not guaranteed to run in Debian.
The easiest fix is
FROM node:18 AS depsIt avoids needing to download another linux image, and produces node_modules consistent with what your build and run images can use.
Flammulated OwlOP
Ohhhh thanks!
I'll be checking then! ðŸ™
Flammulated OwlOP
It worked!
Asian black bear
@Flammulated Owl right on!
Western paper wasp
@Flammulated Owl , just seeing this message. Out of curiosity, are you deploying your NextJS app on GCP (Non-Vercel) provider?
Also to me it's a regression as it was always working, an acceptable one tho
And it stopped suddenly yesterday/previous day
@Flammulated Owl And it stopped suddenly yesterday/previous day
Asian black bear
that is weird, I would have expected it to not work all along. Did you upgrade stuff in package.json or something?
Flammulated OwlOP
Nope 😕
Asian black bear
@Flammulated Owl I dont see it copying package-lock or any other lockfile, so it might actually select newer semver packages sometimes unless you are locking down specific versions in the package.json
even worse, it might actually keep some kind of lockfile or version stickiness from docker cache stuff until it is invalidated/lost
so it would only happen sometimes!
if next started shipping a musl/gnu binary instead of just a generic one at some point this would explain the problem
Flammulated OwlOP
alright ðŸ‘
docker cacheI'm ot using it I'm always building --no-cache
But yeah, no package-lock is bad
Thanks for spoting