Named export 'blue' not found

[ShAsh051]

Describe the bug

I can't sucsessfully run bun run build without getting an error

Reproduction

run bun run build

Expected behaviour

The server builds and I can use bun preview

Logs

node:internal/event_target:1100
process.nextTick(() => { throw err; });
^
file:///C:/Users/Name/MercuryCore/Site/.svelte-kit/output/server/chunks/surreal.js:2
import { blue, green, magenta, red } from "picocolors";
^^^^
SyntaxError: Named export 'blue' not found. The requested module 'picocolors' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from 'picocolors';
const { blue, green, magenta, red } = pkg;

at ModuleJob._instantiate (node:internal/modules/esm/module_job:134:21)
at async ModuleJob.run (node:internal/modules/esm/module_job:217:5)
at async ModuleLoader.import (node:internal/modules/esm/loader:323:24)
at async Promise.all (index 0)
at async analyse (file:///C:/Users/Name/MercuryCore/Site/node_modules/@sveltejs/kit/src/core/postbuild/analyse.js:66:16)
at async MessagePort.<anonymous> (file:///C:/Users/Name/MercuryCore/Site/node_modules/@sveltejs/kit/src/utils/fork.js:22:16)

Emitted 'error' event on Worker instance at:
at [kOnErrorMessage] (node:internal/worker:326:10)
at [kOnMessage] (node:internal/worker:337:37)
at MessagePort. (node:internal/worker:232:57)
at [nodejs.internal.kHybridDispatch] (node:internal/event_target:826:20)
at MessagePort. (node:internal/per_context/messageport:23:28)

Node.js v20.12.2
error: script "build" exited with code 1

System info

Bun 1.1.27, Docker 27.1.1

[lIlIIlIlIII]

I had the same issue. Check out this commit lIlIIlIlIII@5233ef7

[Heliodex]

Ack! I thought I fixed this already, but I changed it back in 0d62bf4. Seems to be an issue with how Bun handles CJS vs ESM, which is odd because it worked fine for me for a long time (it's one of the pain points that caused us to switch from Node to Bun). I'll make a PR to revert it in a sec (sorry if this causes a merge conflict with your work @lIlIIlIlIII, I'll deal with it)

[Heliodex]

Node.js v20.12.2

Hold on a second, this means the script is being run with Node instead of Bun (which Bun does by default for... reasons). Try bun -b run build to actually run the script with Bun, because even though this is fixed you'll run into further problems down the line with Node because the codebase uses many Bun-specific features. Sorry for any confusion.

@lIlIIlIlIII's commit lIlIIlIlIII@5233ef7 also seems to solve this by adding bunx --bun to the beginning of a number of the scripts in package.json, which is a good call. From what I understand, there's a configuration option for Bun (enable-able in bunfig.toml) that allows running all scripts with Bun by default, though I haven't been able to get it to work properly in the past.

[lIlIIlIlIII]

sorry if this causes a merge conflict with your work @lIlIIlIlIII, I'll deal with it

The commit I linked is from a branch where I was experimenting with i18n support. I probably won't create a PR for that branch since the implementation isn't great, so it should be fine.

[Heliodex]

The commit I linked is from a branch where I was experimenting with i18n support. I probably won't create a PR for that branch since the implementation isn't great, so it should be fine.

Looks like awesome work though! I've created #347 and added some more comments to track this.

[lIlIIlIlIII]

The commit I linked is from a branch where I was experimenting with i18n support. I probably won't create a PR for that branch since the implementation isn't great, so it should be fine.

Looks like awesome work though! I've created #347 and added some more comments to track this.

These are some of the things what made me dislike the implementation:

1. It couldn't be used on the server side.
2. The way I defined translation keys was bad.
3. Sometimes, when switching the locale, buttons wouldn't change until I visited another page and then came back.
4. After refreshing the page, the locale would always be the default (en-US) for a second and then switch to the stored locale.