EPIPE on Mac (Apple Silicon)

When using sass-loader with sass-embedded in rspack, I get the following error:

> RSPACK_CONFIG_VALIDATE=loose rspack build

node:events:495
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE
    at afterWriteDispatched (node:internal/stream_base_commons:160:15)
    at writeGeneric (node:internal/stream_base_commons:151:3)
    at Socket._writeGeneric (node:net:962:11)
    at Socket._write (node:net:974:8)
    at writeOrBuffer (node:internal/streams/writable:392:12)
    at _write (node:internal/streams/writable:333:10)
    at Writable.write (node:internal/streams/writable:337:10)
    at AsyncCompiler.writeStdin ((omitted for privacy)/node_modules/sass-embedded/dist/lib/src/compiler/async.js:60:28)
    at PacketTransformer.writeInboundBuffer ((omitted for privacy)/node_modules/sass-embedded/dist/lib/src/compiler/async.js:114:18)
    at PacketTransformer.writeInboundProtobuf ((omitted for privacy)/node_modules/sass-embedded/dist/lib/src/packet-transformer.js:68:18)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -32,
  code: 'EPIPE',
  syscall: 'write'
}

Node.js v18.20.3

Loader configuration:

{
    loader: 'sass-loader',
    options: {
        api: 'modern-compiler',
        implementation: require.resolve('sass-embedded'),
        sassOptions: {
            logger: console,
            includePaths: [
                injectable('styles'),
                src('styles'),
                src('.'),
            ],
        },
    },
},

    "sass-embedded": "^1.89.2",
    "sass-loader": "^16.0.5",

Honestly not sure what to do. Any help would be appreciated.

It looks like the embedded compiler has closed suddenly and not gracefully. We could add more error handling for this, but it would only result in producing a more legible error message saying something like "The embedded compiler catastrophically failed", so I'm not sure it's worth obscuring the actual failure.

Can you reproduce this with just the embedded Sass API, without rspack involved?

It looks like the embedded compiler has closed suddenly and not gracefully. We could add more error handling for this, but it would only result in producing a more legible error message saying something like "The embedded compiler catastrophically failed", so I'm not sure it's worth obscuring the actual failure.

Can you reproduce this with just the embedded Sass API, without rspack involved?

Could you please provide some ideas on how could I try to reproduce this without involving rspack?

The documentation for the Sass JS API is here. If just using the API on its own isn't enough, you may need to work with the rspack maintainers to try to find a minimal version of whatever importer or API pattern they're using that's triggering this.

same

ynode:events:502
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE
    at afterWriteDispatched (node:internal/stream_base_commons:159:15)
    at writeGeneric (node:internal/stream_base_commons:150:3)
    at Socket._writeGeneric (node:net:971:11)
    at Socket._write (node:net:983:8)
    at writeOrBuffer (node:internal/streams/writable:572:12)
    at _write (node:internal/streams/writable:501:10)
    at Writable.write (node:internal/streams/writable:510:10)
    at AsyncCompiler.writeStdin......
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
  errno: -32,
  code: 'EPIPE',
  syscall: 'write'
}

Node.js v22.13.1

in webpack

"sass-embedded": "^1.90.0",
"react-scripts": "^5.0.1",
"@craco/craco": "^7.1.0",

Can you please run the following command and check the output?

node ./node_modules/sass-embedded/dist/bin/sass.js --version

It should just print 1.90.0 on macOS.

If you are seeing 1.90.0 compiled with dart2js 3.8.3 or getting an error, tell us what you're seeing. Most likely you're missing an optional dependency, which is supposed to be installed automatically in normal cases.

@ntkme

@ntkme

$ node ./node_modules/sass-embedded/dist/bin/sass.js --version
1.90.0

here is my macOS output.

the error I mentioned above only happened once, and my Sass can compile CSS normally.

same

ynode:events:502
throw er; // Unhandled 'error' event
^

Error: write EPIPE
at afterWriteDispatched (node:internal/stream_base_commons:159:15)
at writeGeneric (node:internal/stream_base_commons:150:3)
at Socket._writeGeneric (node:net:971:11)
at Socket._write (node:net:983:8)
at writeOrBuffer (node:internal/streams/writable:572:12)
at _write (node:internal/streams/writable:501:10)
at Writable.write (node:internal/streams/writable:510:10)
at AsyncCompiler.writeStdin......
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
Emitted 'error' event on Socket instance at:
at emitErrorNT (node:internal/streams/destroy:170:8)
at emitErrorCloseNT (node:internal/streams/destroy:129:3)
at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
errno: -32,
code: 'EPIPE',
syscall: 'write'
}

Node.js v22.13.1
in webpack 在 webpack 中

"sass-embedded": "^1.90.0",
"react-scripts": "^5.0.1",
"@craco/craco": "^7.1.0",

the error I mentioned above only happened once, and my Sass can compile CSS normally.

The error means the dart-sass compiler somehow crashed unexpectedly. If it only happened once there isn't much we can do, unless someone discovers a way to reliably reproduce the crash.

I'm seeing the same issue in a Nuxt 4 application that utilizes Vite 7

------------------------------
- Operating System: Darwin
- Node Version:     v24.11.0
- Nuxt Version:     4.2.1
- CLI Version:      3.30.0
- Nitro Version:    2.12.9
- Package Manager:  pnpm@10.19.0
- Builder:          -
- User Config:      -
- Runtime Modules:  -
- Build Modules:    -
------------------------------

Same question as above: can you reproduce this reliably with code that directly uses the Sass API?

I can put together a small reproduction utilizing the default nuxt 4 scaffolding but you'd have to run it specifically on Apple Silicon in order to reproduce. The issue only seems to arise during hot module reload.

A Nuxt reproduction doesn't really help—we'd need to be able to isolate and test the issue with our own APIs to be sure that we've actually implemented a fix.

Not certain, but it’s possible that webpack-sass-loader is disposing compiler at wrong timing.

I checked the source code that we have a check for whether compiler is closed or not inside sendCompileRequest that it would throw a different error. However, there is no check in sendInboundMessage for sending responses where it’s possible to get a EPIPE. So it’s entirely possible that it’s disposing a compiler while another request is in flight.

A Nuxt reproduction doesn't really help—we'd need to be able to isolate and test the issue with our own APIs to be sure that we've actually implemented a fix.

Yep. I'm fairly certain it's a combination of module settings between Nuxt DevTools and specific extension.

Once I can dig in there, I should be able to find the root cause.

Apologies for the noise here

+1 getting this error randomly in our CI env (LXC) with vite 7 and vite 8

@shining-mind

@shining-mind Same question as I've asked everyone else: can you find a consistent minimal reproduction?

@shining-mind

@shining-mind Same question as I've asked everyone else: can you find a consistent minimal reproduction?

It's not that easy, we will try to look into it.
It would help if you would add more detailed logging into the compiler, so that we could at least identify the file were the issue occurs.

It would help if you would add more detailed logging into the compiler, so that we could at least identify the file were the issue occurs.

One thing I noticed is that the compiler's stderr, which is used for reporting internal errors, is listened on event loop and then bubbled to parent process' stderr. The problem with this approach is that if the main event loop encounters a fatal crash, the event for child process stderr event might never get a chance to execute at all.

I purpose that instead of listen on stderr event, we change it to use spawnOptions.stdio = ['pipe', 'pipe', 'inherit']. So the child process stderr will get directly flushed to parent process' stderr file descriptor and never be blocked by event loop, giving it a much higher chance to report the internal error if any.

That makes sense to me. Will it work on Windows or will we need to have an OS check and fallback?

inherit should work on windows.

+1 same error

node 24

"@rspack/core": "1.7.11",
"sass": "1.99.0",
"sass-loader": "16.0.7",
"sass-embedded": "1.99.0",

MacOs 15.7.4

Navigation Menu

Repository navigation

EPIPE on Mac (Apple Silicon) #387

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

EPIPE on Mac (Apple Silicon) #387

Description

Activity

nex3 commented on Jul 14, 2025

brotheroftux commented on Jul 15, 2025

nex3 commented on Jul 15, 2025

SolidZORO commented on Aug 22, 2025

ntkme commented on Aug 22, 2025

SolidZORO commented on Aug 22, 2025

ntkme commented on Aug 22, 2025

adamdehaven commented on Nov 12, 2025

nex3 commented on Nov 12, 2025

adamdehaven commented on Nov 13, 2025

nex3 commented on Nov 13, 2025

ntkme commented on Nov 13, 2025

adamdehaven commented on Nov 13, 2025

shining-mind commented on Apr 21, 2026

nex3 commented on Apr 21, 2026

shining-mind commented on Apr 21, 2026

ntkme commented on Apr 21, 2026

nex3 commented on Apr 21, 2026

ntkme commented on Apr 21, 2026

bratva commented on Apr 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions