Node-sass: Docker ALPINE Linux throws node-sass missing binding error

[gkatsanos]

• NPM version (npm -v): 5.5.1 (but using yarn latest)
• Node version (node -v): 8.9.1
• Node Process (node -p process.versions):

{ http_parser: '2.7.0',
  node: '8.9.1',
  v8: '6.1.534.47',
  uv: '1.15.0',
  zlib: '1.2.11',
  ares: '1.10.1-DEV',
  modules: '57',
  nghttp2: '1.25.0',
  openssl: '1.0.2m',
  icu: '59.1',
  unicode: '9.0',
  cldr: '31.0.1',
  tz: '2017b' }```
- Node Platform (`node -p process.platform`): linux

- Node architecture (`node -p process.arch`): x64
- node-sass version (`node -p "require('node-sass').info"`):

/app # node -p "require('node-sass').info"

/app/node_modules/node-sass/lib/binding.js:15
      throw new Error(errors.missingBinary());
      ^

Error: Missing binding /app/node_modules/node-sass/vendor/linux_musl-x64-57/binding.node
Node Sass could not find a binding for your current environment: Linux/musl 64-bit with Node.js 8.x

Found bindings for the following environments:
  - OS X 64-bit with Node.js 8.x

This usually happens because your environment has changed since running `npm install`.
Run `npm rebuild node-sass --force` to build the binding for your current environment.
    at module.exports (/app/node_modules/node-sass/lib/binding.js:15:13)
    at Object.<anonymous> (/app/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (module.js:635:30)
    at Object.Module._extensions..js (module.js:646:10)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Module.require (module.js:579:17)
    at require (internal/module.js:11:18)
    at [eval]:1:1

• npm node-sass versions (npm ls node-sass):
  -- [email protected]

So that's the Dockerfile:

FROM node:8-alpine

EXPOSE 3000

ARG NODE_ENV
ENV NODE_ENV $NODE_ENV

RUN mkdir /app
WORKDIR /app
ADD . /app
RUN yarn --pure-lockfile

and the compose 'dev' file:

version: "3"
services:
  client:
    command: yarn dev

which runs:
"dev": "node build/dev-server.js",
(it's a vue-cli script that uses webpack-dev-middleware)

and then.. :

~/v/i/client (master|●6✚7) $ yarn docker:dev yarn run v1.3.2 $ docker-compose -f docker-compose.yml -f docker-compose.dev.yml up WARNING: Some services (client) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm. Recreating client_client_1 ... Recreating client_client_1 ... done Attaching to client_client_1 client_1 | yarn run v1.3.2 client_1 | $ node build/dev-server.js client_1 | > Starting dev server... client_1 | ERROR Failed to compile with 1 errors16:51:31 client_1 | client_1 | error in ./src/components/Wrapper/wrapper.scss client_1 | client_1 | Module build failed: Error: Missing binding /app/node_modules/node-sass/vendor/linux_musl-x64-57/binding.node client_1 | Node Sass could not find a binding for your current environment: Linux/musl 64-bit with Node.js 8.x client_1 | client_1 | Found bindings for the following environments: client_1 | - OS X 64-bit with Node.js 8.x client_1 | client_1 | This usually happens because your environment has changed since running `npm install`. client_1 | Run `npm rebuild node-sass --force` to build the binding for your current environment. client_1 | at module.exports (/app/node_modules/node-sass/lib/binding.js:15:13) client_1 | at Object.<anonymous> (/app/node_modules/node-sass/lib/index.js:14:35)

How come node-sass sees OSX bindings? I thought it's an image/container...

[xzyfer]

You can't mount native modules into different OSes. Run non rebuild
node-sass on the container to get the right binding.

On 26 Nov. 2017 3:59 am, "George Katsanos" [e-mail] wrote:

>

• NPM version (npm -v): 5.5.1 (but using yarn latest)
• Node version (node -v): 8.9.1
• Node Process (node -p process.versions):

{ http_parser: '2.7.0',
node: '8.9.1',
v8: '6.1.534.47',
uv: '1.15.0',
zlib: '1.2.11',
ares: '1.10.1-DEV',
modules: '57',
nghttp2: '1.25.0',
openssl: '1.0.2m',
icu: '59.1',
unicode: '9.0',
cldr: '31.0.1',
tz: '2017b' }```

• Node Platform (node -p process.platform): linux

• Node architecture (node -p process.arch): x64
• node-sass version (node -p "require('node-sass').info"):

/app # node -p "require('node-sass').info"
/app/node_modules/node-sass/lib/binding.js:15
throw new Error(errors.missingBinary());
^

Error: Missing binding /app/node_modules/node-sass/
vendor/linux_musl-x64-57/binding.node
Node Sass could not find a binding for your current environment:
Linux/musl 64-bit with Node.js 8.x

Found bindings for the following environments:

• OS X 64-bit with Node.js 8.x

This usually happens because your environment has changed since running npm
install.
Run npm rebuild node-sass --force to build the binding for your current
environment.
at module.exports (/app/node_modules/node-sass/lib/binding.js:15:13)
at Object. (/app/node_modules/node-sass/lib/index.js:14:35)
at Module._compile (module.js:635:30)
at Object.Module._extensions..js (module.js:646:10)
at Module.load (module.js:554:32)
at tryModuleLoad (module.js:497:12)
at Function.Module._load (module.js:489:3)
at Module.require (module.js:579:17)
at require (internal/module.js:11:18)
at [eval]:1:1

• npm node-sass versions (npm ls node-sass):
  `-- [email protected]

~/v/i/client (master|●6✚7) $ yarn docker:dev
yarn run v1.3.2
$ docker-compose -f docker-compose.yml -f docker-compose.dev.yml up
WARNING: Some services (client) use the 'deploy' key, which will be
ignored. Compose does not support 'deploy' configuration - use docker
stack deploy to deploy to a swarm.
Recreating client_client_1 ...
Recreating client_client_1 ... done
Attaching to client_client_1
client_1 | yarn run v1.3.2
client_1 | $ node build/dev-server.js
client_1 | > Starting dev server...
client_1 | ERROR Failed to compile with 1 errors16:51:31
client_1 |
client_1 | error in ./src/components/Wrapper/wrapper.scss
client_1 |
client_1 | Module build failed: Error: Missing binding
/app/node_modules/node-sass/vendor/linux_musl-x64-57/binding.node
client_1 | Node Sass could not find a binding for your current
environment: Linux/musl 64-bit with Node.js 8.x
client_1 |
client_1 | Found bindings for the following environments:
client_1 | - OS X 64-bit with Node.js 8.x
client_1 |
client_1 | This usually happens because your environment has changed since
running npm install.
client_1 | Run npm rebuild node-sass --force to build the binding for
your current environment.
client_1 | at module.exports (/app/node_modules/node-sass/
lib/binding.js:15:13)
client_1 | at Object. (/app/node_modules/node-sass/lib/index.js:14:35)```

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2165, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWKTeF3GLBSgPw4qcdFbCTPtgLXUgks5s6EdvgaJpZM4QqfQk
.

[gkatsanos]

I appreciate the swift reply but I'm afraid I did not understand the answer. (probably because the concept of docker is unclear still to me)
I have the package json file and I'm running yarn install in the dockerfile therefore I expect yarn / npm to fetch the proper package for the O/S my docker is running on? (alpine in my case)
What am I doing wrong there?

[xzyfer]

Because you're mounting your node_modules folder running yarn isn doing
nothing because all the packages look iike their installed. You should
avoid mounting node_modules, instead mount the specific folders with your
code.

On 26 Nov. 2017 9:35 am, "George Katsanos" [e-mail] wrote:

I appreciate the swift reply but I'm afraid I did not understand the
answer. (probably because the concept of docker is unclear still to me)
I have the package json file and I'm running yarn install in the
dockerfile therefore I expect yarn / npm to fetch the proper package for
the O/S my docker is running on? (alpine in my case)
What am I doing wrong there?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2165#issuecomment-346970741,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWPxl3aLDwPgS9trYYa5zucAPdWyDks5s6JYxgaJpZM4QqfQk
.

[gkatsanos]

For the future adventurer:
1/ create a .dockerignore file with

npm-debug.log

2/ proceed as usual

# Dockerfile
RUN mkdir /app
WORKDIR /app
COPY . /app
RUN yarn --pure-lockfile

3/ you will probably need to mount node_modules as a volume in your docker-compose.yml file

version: "3"
services:
  client:
    image: username/dockerReponame
    build: .
    volumes:
      - .:/app
      - /app/node_modules/

[harshes53]

what about production setup?

[xzyfer]

what about production setup?

npm install node-sass@latest

We supply Alpine binaries for newer version of node-sass.

[bkuhl]

Are you saying this is no longer an issue in later versions of node-sass?

[xzyfer]

This is not an issue, it's just how Node works. Native modules are built for a specific Node version, OS, and architecture combination i.e. Node 6 on 64-bit OSX.

Each release shows it's support matrix i.e. https://github.com/sass/node-sass/releases/tag/v4.8.3

The issue here is that OP had installed node-sass OS X 64-bit with Node.js 8.x, then mounted node_modules into a Linux docker container. Clearly that OS X binary could not work on Linux OS. The solution is to run npm rebuild node-sass in the container to pull the correct binary.

In production you would not be mounting files in to the container so npm install is all you would need because it will fetch the correct binary for the container.

[yfaney]

@xzyfer
Hey I am not sure if this works for everybody but this one fixed our issue:

npm uninstall node-sass && npm install node-sass --sass-binary-name=linux-x64-57

Or you can replace linux-x64-57 with the environment name you desire.

[JulianeAlbuquerque]

Hello, I had the same problem and I fixed it using export SASS_BINARY_NAME=linux-x64-57
but now I had other problem:

Module build failed: ModuleBuildError: Module build failed: Error: /usr/src/ps-ibanking/node_modules/node-sass/vendor/linux-x64-57/binding.node: invalid ELF header
    at Object.Module._extensions..node (module.js:681:18)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at module.exports (/usr/src/ps-ibanking/node_modules/node-sass/lib/binding.js:19:10)
    at Object.<anonymous> (/usr/src/ps-ibanking/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/usr/src/ps-ibanking/node_modules/sass-loader/lib/loader.js:3:14)
    at runLoaders (/usr/src/ps-ibanking/node_modules/webpack/lib/NormalModule.js:195:19)
    at /usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:364:11
    at /usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:170:18
    at loadLoader (/usr/src/ps-ibanking/node_modules/loader-runner/lib/loadLoader.js:27:11)
    at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:169:2)
    at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:165:10)
    at /usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:173:18
    at loadLoader (/usr/src/ps-ibanking/node_modules/loader-runner/lib/loadLoader.js:36:3)
    at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:169:2)
    at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:165:10)
    at /usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:173:18
    at loadLoader (/usr/src/ps-ibanking/node_modules/loader-runner/lib/loadLoader.js:36:3)
    at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:169:2)
    at runLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:362:2)
    at NormalModule.doBuild (/usr/src/ps-ibanking/node_modules/webpack/lib/NormalModule.js:182:3)
    at NormalModule.build (/usr/src/ps-ibanking/node_modules/webpack/lib/NormalModule.js:275:15)

I'm using the same config in my OSX and in Docker:

• NPM 5.6.0
• NODE v8.11.3

[xzyfer]

Alpine cannot use the Linux binary. It has it's own binary. There's is no
need to do what you're doing. Instead run npm rebuild node-sass

On Sat., 28 Jul. 2018, 2:41 am Juliane Albuquerque, <
[email protected]> wrote:

Hello, I had the same problem and I fixed it using export
SASS_BINARY_NAME=linux-x64-57
but now I had other problem:

Module build failed: ModuleBuildError: Module build failed: Error: /usr/src/ps-ibanking/node_modules/node-sass/vendor/linux-x64-57/binding.node: invalid ELF header
at Object.Module._extensions..node (module.js:681:18)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Module.require (module.js:596:17)
at require (internal/module.js:11:18)
at module.exports (/usr/src/ps-ibanking/node_modules/node-sass/lib/binding.js:19:10)
at Object. (/usr/src/ps-ibanking/node_modules/node-sass/lib/index.js:14:35)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Module.require (module.js:596:17)
at require (internal/module.js:11:18)
at Object. (/usr/src/ps-ibanking/node_modules/sass-loader/lib/loader.js:3:14)
at runLoaders (/usr/src/ps-ibanking/node_modules/webpack/lib/NormalModule.js:195:19)
at /usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:364:11
at /usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:170:18
at loadLoader (/usr/src/ps-ibanking/node_modules/loader-runner/lib/loadLoader.js:27:11)
at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:169:2)
at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:165:10)
at /usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:173:18
at loadLoader (/usr/src/ps-ibanking/node_modules/loader-runner/lib/loadLoader.js:36:3)
at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:169:2)
at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:165:10)
at /usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:173:18
at loadLoader (/usr/src/ps-ibanking/node_modules/loader-runner/lib/loadLoader.js:36:3)
at iteratePitchingLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:169:2)
at runLoaders (/usr/src/ps-ibanking/node_modules/loader-runner/lib/LoaderRunner.js:362:2)
at NormalModule.doBuild (/usr/src/ps-ibanking/node_modules/webpack/lib/NormalModule.js:182:3)
at NormalModule.build (/usr/src/ps-ibanking/node_modules/webpack/lib/NormalModule.js:275:15)

I'm using the same config in my OSX and in Docker:

• NPM 5.6.0
• NODE v8.11.3

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2165#issuecomment-408474157,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWFYvp6vo6FkLpKF0TF9XS8qU2Ppjks5uK0K1gaJpZM4QqfQk
.

[JulianeAlbuquerque]

It works, thanks!

[yfaney]

Now I see what's wrong with me. My script has a sub npm project for Docker which has another node_modules directory under client which prevents me from having linux binary instead of darwin.
'rm -rf node_modules && rm -rf client/node_modules' before running docker-compose --build ultimately fixed my issue. FYI.

[tcfunk]

Wanted to report on my experience with this just now. My container was still getting the wrong binding, even when mounting the node_modules folder as a named volume like so:

services:
  web:
    volumes:
      node_modules:/usr/src/app/node_modules

volumes:
  node_modules:

Turns out that (at least on Windows), if you call your named volume node_modules, it still seems to be causing some sort of confusion/collision with the folder. Changing the name of my volume fixed the issue.

[bcdevworks]

I did this in my Dockerfile:

CMD ["npm", "rebuild", "node-sass"]
CMD ["npm", "start"]

[zubhav]

Tried several fixes stated above. But what worked for me is removing the container/image manually and forcing docker-compose to rebuild from scratch.

[alexkunin]

Had similar issue while using official node docker image:

FROM node:11.1-alpine
...
> [email protected] install /app/node_modules/node-sass
> node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.9.3/linux_musl-x64-67_binding.node
Cannot download "https://github.com/sass/node-sass/releases/download/v4.9.3/linux_musl-x64-67_binding.node": 

HTTP error 404 Not Found

There is no node-sass binary for this node version, so, I had to downgrade to 10:

FROM node:10-alpine

[xzyfer]

Duplicate

On Sun., 4 Nov. 2018, 9:03 am Alex Kunin <[email protected] wrote:

Had similar issue while using official node docker image:

FROM node:11.1-alpine
...

[email protected] install /app/node_modules/node-sass
node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.9.3/linux_musl-x64-67_binding.node
Cannot download "https://github.com/sass/node-sass/releases/download/v4.9.3/linux_musl-x64-67_binding.node":

HTTP error 404 Not Found

There is no node-sass binary for this node version, so, I had to downgrade
to 10:

FROM node:10-alpine

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2165#issuecomment-435624466,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWC1UmCMAS3lIjAwzPX0zQQEAj3Isks5urhLNgaJpZM4QqfQk
.

[mcshaman]

I switch between builds on my local machine and docker containers in some projects. Node SASS is the only binary I have come across that seems to bork at the different operating systems. I basically have to run a rebuild every compile just in case I am in a different environment. Couldn't Node SASS include all bindings and server up the correct one at runtime?

[gruckion]

I did this in my Dockerfile:

CMD ["npm", "rebuild", "node-sass"]
CMD ["npm", "start"]

You should not use more than one CMD statement in your dockerfile
Why can't I use Docker CMD multiple times to run multiple services?

[GanymedeIndustries]

Hey all, sorry for re-opening this, but if you want to volume mount your host built node_modules AND have node-sass running, then you can instead build an image using your local OS and not use the pre-built node alpine image. Yes it is lengthy, but its only for development.

I use ubuntu (well ubuntu on WSL, hence the angular cli install that you'll see later on), so I can just use the ubuntu image, install node, yarn and other things, then setup my app. Below is a real crude/just get it working Dockerfile to get my angular app (that using node sass) compiling and running:

FROM ubuntu:latest

RUN apt-get update

# Is optional, but if you are not going to use this then you will need to install
# 'gnupg' for nodesource so it can setup node install
RUN apt-get install -y build-essential

RUN apt-get -y install curl

# The next 2 steps will install node 10.15.1
RUN curl -sL https://deb.nodesource.com/setup_10.x | bash -

RUN apt-get install -y nodejs

# The next 3 steps are for installing yarn
RUN curl -sL https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -

RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" > /etc/apt/sources.list.d/yarn.list

RUN apt-get update && apt-get install yarn

# The above was setting the 'OS' only, so you can make that a separate image to save
# alot of time building the app-only image

WORKDIR /usr/src/app

# Bug in WSL and docker for windows means that symlinks aren't created properly,
# so below is useless until its fixed
# ENV PATH=$PATH:/usr/src/app/node_modules/.bin

RUN yarn global add "@angular/cli"

EXPOSE 4200

CMD [ "yarn", "start" ]

Yes, real crude, but it works, so now I can volume mount my entire app to the WORKDIR and it will compile without any issues. Like I said in the comments, I'd suggest you create a separate image for the 'OS' part to save alot of time building it, but this really was for-the-win type concept.

[Baldrani]

You need to build your node_modules from your docker :

docker-compose run --rm client npm install
docker-compose restart client

(Using docker compose ofc)

[rkaw92]

Note: this is also relevant when building binaries with zeit/pkg: since the Node.js binary is compiled against musl libc (apparently, or so node-sass thinks), you need to set SASS_BINARY_NAME.
Otherwise, you'll get something along the lines of:

Node Sass could not find a binding for your current environment: Linux/musl 64-bit with Node.js 12.x

[c0bra]

For anyone attempting to do local development with docker-compose, I was able to get this working by adding an npm command "docker:start": "npm rebuild node-sass && npm start" and then using command: npm run docker:start in my compose file.

node_modules is in .dockerignore but the whole working directory is being mounted in as a volume.

[lane-eb]

For me, I have the problem with yarn.
After two hours research, I fixed this error by
docker exec -it myproject_frontend_1 bash and then run
yarn add node-sass.

[yixikkjkj]

It's helpful for me. Webpack seem to find node-sass from the context folder, and if the os x node_modules is mounted as a volume, the error will happen. In this case, using a empty volume instead of the os x node_modules will be great. You shall write as:

    volumes:
      - .:/app
      - /app/node_modules/

Make the node_modules empty!~

[CodTicker]

So I just came across this:

Error: Missing binding /app/node_modules/node-sass/vendor/linux_musl-x64-79/binding.node
client_1 | Node Sass could not find a binding for your current environment: Linux/musl 64-bit with Node.js 13.x
client_1 |
client_1 | Found bindings for the following environments:
client_1 | - Windows 64-bit with Node.js 10.x
client_1 |
client_1 | This usually happens because your environment has changed since running npm install.
client_1 | Run npm rebuild node-sass to download the binding for your current environment.

Sass version: "node-sass": "^4.14.1",
node: 10.16.1

dockerFile:

FROM node:13.12.0-alpine

# set working directory
WORKDIR /app

# add `/app/node_modules/.bin` to $PATH
ENV PATH /app/node_modules/.bin:$PATH

# install app dependencies
# COPY package.json ./
RUN npm install --silent
RUN npm install [email protected] -g --silent
RUN npm rebuild node-sass

# add app
COPY . /app


CMD ["npm", "start"]

dockerCompose:

  client:
    container_name: weddingapp_client
    build: ./weddingApp-Fe
    volumes:
      - "./weddingApp-Fe/.:/app"
      - "./weddingApp-Fe/app/node_modules"
    ports:
      - 3001:3000
    environment:
      - CHOKIDAR_USEPOLLING=true
    tty: true

What am I missing?

Tried several options above but nothing works.

[alexkunin]

@CodTicker, you seem to have correct Dockerfile which installs/builds Linux version of node-sass for Node 13 -- if that Dockerfile yields you a proper image, then this part is totally fine.

But in your docker-compose.yml you mount few local folders inside container, including node_modules, and apparently you did npm i/npm ci on your host machine too, and that machine seems to be Windows. And now that mount -- specifically - "./weddingApp-Fe/app/node_modules" -- is in your way. TBH, maybe both mounts are in your way, I'm not sure what second one does.

So, this is what happens:

1. Dockerfile is processed, you get proper image, with valid Linux node-sass binaries.
2. Then you create container from that image via docker-compose, so far so good.
3. And then you run that container, but you also substitute whole node_modules with something else which resides on your host machine.
4. Inside the container, your app tries to load Linux node-sass binaries prepared in p.1 above, what all it finds is some Windows binaries which are there due to p.3.

To fix that, comment out volumes from your docker-compose.yml and restart containers.