Preprocess config not working (postcss, babel, etc)

[yuanchuan]

Describe the bug

The preprocess config breaks after version 1.0.0-next.146

This issue is probably caused by #2137. After small investigation I found the error happens only when no cache is detected and vite tries to rebuild everyting with config.

https://github.com/vitejs/vite/blob/fb406ce4c0fe6da3333c9d1c00477b2880d46352/packages/vite/src/node/build.ts#L385-L387

Reproduction

https://github.com/yuanchuan/sveltekit-issues/tree/main/preprocess-not-working

Logs

No response

System Info

System:
    OS: macOS 11.1
    CPU: (4) x64 Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz
    Memory: 390.95 MB / 8.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.5.0 - ~/.nvm/versions/node/v16.5.0/bin/node
    Yarn: 1.3.2 - /usr/local/bin/yarn
    npm: 7.19.1 - ~/.nvm/versions/node/v16.5.0/bin/npm
  Browsers:
    Chrome: 92.0.4515.159
    Edge: 92.0.902.78
    Firefox: 72.0.2
    Firefox Nightly: 92.0a1
    Safari: 14.0.2
    Safari Technology Preview: 14.2
  npmPackages:
    @sveltejs/kit: 1.0.0-next.146 => 1.0.0-next.146
    svelte: 3.42.1 => 3.42.1

Severity

blocking an upgrade

Additional Information

No response

[bluwy]

There are logs when running the repro. Here's mine:

 > html:/home/bjorn/Documents/projects/playground/preprocess-not-working/src/routes/index.svelte:3:29: error: Unexpected ">"
    3 │   let title = 'hello world' |> uppercase;
      ╵                              ^

> Build failed with 1 error:
html:/home/bjorn/Documents/projects/playground/preprocess-not-working/src/routes/index.svelte:3:29: error: Unexpected ">"
Error: Build failed with 1 error:
html:/home/bjorn/Documents/projects/playground/preprocess-not-working/src/routes/index.svelte:3:29: error: Unexpected ">"
    at failureErrorWithLog (/home/bjorn/Documents/projects/playground/preprocess-not-working/node_modules/esbuild/lib/main.js:1449:15)
    at /home/bjorn/Documents/projects/playground/preprocess-not-working/node_modules/esbuild/lib/main.js:1131:28
    at runOnEndCallbacks (/home/bjorn/Documents/projects/playground/preprocess-not-working/node_modules/esbuild/lib/main.js:921:63)
    at buildResponseToResult (/home/bjorn/Documents/projects/playground/preprocess-not-working/node_modules/esbuild/lib/main.js:1129:7)
    at /home/bjorn/Documents/projects/playground/preprocess-not-working/node_modules/esbuild/lib/main.js:1236:14
    at /home/bjorn/Documents/projects/playground/preprocess-not-working/node_modules/esbuild/lib/main.js:609:9
    at handleIncomingPacket (/home/bjorn/Documents/projects/playground/preprocess-not-working/node_modules/esbuild/lib/main.js:706:9)
    at Socket.readFromStdout (/home/bjorn/Documents/projects/playground/preprocess-not-working/node_modules/esbuild/lib/main.js:576:7)
    at Socket.emit (events.js:315:20)
    at Socket.EventEmitter.emit (domain.js:467:12)

Looks like Vite's import scan runs esbuild on the code, which causes the error. I couldn't find an existing issue in Vite though, since this should technically affect other SFCs like Vue any other files that uses this syntax regardless of babel installed. Otherwise we may want to report this in Vite.

[bluwy]

Found a vite issue: vitejs/vite#1450. It's closed but it's not really fixed per vitejs/vite@0503d42#commitcomment-45804097

[benmccann]

It looks like this is called the pipeline operator:

• https://github.com/tc39/proposal-pipeline-operator
• https://babeljs.io/docs/en/babel-plugin-proposal-pipeline-operator

I'm not really sure how this could be fixed other than by esbuild adding support for the pipeline operator or Vite somehow completely reimplementing dependency scanning. You could request support for the pipeline operator from esbuild. I think for now I would just say that experimental syntax is not supported

[yuanchuan]

For anyone is experiencing the same, add the follwing to svelte.config.js should fix the issue. See #2180

vite: {
  optimizeDeps: {
    entries: []
  }
}

[bluwy]

I'd do that with caution, that will basically turn off pre-bundling and you have to make sure all dependencies have an ESM export variant, or manually add dependencies to optimizeDeps.include yourself.

[yuanchuan]

Thanks for reminding. That's the only solution I could find to get back the behavior before 1.0.0-next.146, which works pretty fine for me. Optimization is not necessary.