Esbuild --bundle fails to resolve import call in obfuscated_import

[razshare]

Describe the bug

This is related to #17762 .

Looking back it should've been obvious... since the static analyzer no longer sees the import() call, esbuild no longer resolves it in --bundle mode (docs), so the resulting source code looks like this:

var obfuscated_import = (module_name) => import(
  /* @vite-ignore */
  module_name
);

There's obviously no error at build time, it just hits you at runtime when running the .cjs file because... well, esbuild is supposed to resolve the import(), but it's not, and a cjs only runtime has no idea what import() is.

I honestly don't know if this is fixable unless node:crypto is dropped, aka node 18 is dropped.

Another alternative would be to use a userland crypto package instead of something from the platform, but I don't know if that's doable or even worth it, this is getting ridiculous.

I'll come up with some patch-work on my end, I'll probably have to straight up remove that code from the bundle and cross my fingers.

I'm just opening this because I thought I should let you guys know about the issue.

Reproduction

Full reproduction can be found here https://github.com/razshare/svelte-reproduction-issue-17771

Logs

make build 
npx vite build --logLevel=info --outDir=dist/server --emptyOutDir=true --ssr=app.server.ts
vite v7.3.1 building ssr environment for production...
✓ 114 modules transformed.
dist/server/app.server.js  32.32 kB
✓ built in 249ms
./node_modules/.bin/esbuild --bundle --outfile=dist/server/app.server.cjs --format=cjs --allow-overwrite dist/server/app.server.js

  dist/server/app.server.cjs  46.1kb

⚡ Done in 4ms

System Info

System:
    OS: Linux 6.12 Debian GNU/Linux 13 (trixie) 13 (trixie)
    CPU: (32) x64 AMD Ryzen 9 5950X 16-Core Processor
    Memory: 112.19 GB / 125.69 GB
    Container: Yes
    Shell: 5.2.37 - /bin/bash
  Binaries:
    Node: 24.12.0 - /home/raz/.nvm/versions/node/v24.12.0/bin/node
    Yarn: 1.22.22 - /home/raz/.nvm/versions/node/v24.12.0/bin/yarn
    npm: 11.6.2 - /home/raz/.nvm/versions/node/v24.12.0/bin/npm
    pnpm: 10.30.1 - /home/raz/.local/share/pnpm/pnpm
    bun: 1.3.9 - /home/raz/.bun/bin/bun
  Browsers:
    Brave Browser: 144.1.86.139

Severity

annoyance

[Conduitry]

Does the other base64 solution work? Does esbuild compile that into a require?

[razshare]

Does the other base64 solution work?

No, it seems to behave the same way, esbuild doesn't complain about it, but then it obviously also doesn't resolve the import.

Does esbuild compile that into a require?

No, it doesn't compile it to require(), it just leaves it as import().

This is what the final .cjs file looks like

I mean it makes sense, we can't have it both ways, if we don't want esbuild to know about the import() then it won't resolve it, but if esbuild knows about it then it will try to resolve the module and crash.

[razshare]

Is it possible for the svelte package to somehow overwrite the module name forcefully in userland?

I'm asking because overwriting the module name in jsconfig.json/tsconfig.json seems to work.

So in jsconfig.json

{
    "compilerOptions": {
        "node:crypto": ["./custom_crypto.js"]
    }
}

and then custom_crypto.js

// custom_crypto.js
export const webcrypto = {
  subtle: {
    digest(algorithm, text) {},
  },
};

the resulting .cjs file is

// dist/server/app.server.cjs
var crypto;
async function sha256(data) {
  text_encoder ??= new TextEncoder();
  crypto ??= globalThis.crypto?.subtle?.digest ? globalThis.crypto : (
    // @ts-ignore - we don't install node types in the prod build
    // don't use import('node:crypto') directly because static analysers will think we rely on node when we don't
    (await Promise.resolve().then(() => (init_custom_crypto(), custom_crypto_exports))).webcrypto
  );
  const hash_buffer = await crypto.subtle.digest("SHA-256", text_encoder.encode(data));
  return base64_encode(hash_buffer);
}

It resolves it.

I know this would be possible in sveltekit because by default the base project extends an internal definition of jsconfig.json, so you would just overwrite the module in the internal definition, but I'm not sure if that's possible in svelte since it's just a package.

I'm just throwing things at the wall here.

[dummdidumm]

It is possible to create require from import.meta.something I believe. Could we use that (with try-catch, and try falling back to native require) in the obfuscated import?

let req;
try {
  req = ...
} catch {
  req = require
}

[razshare]

It could work for runtimes that implement nodejs stdlib, but the issue here is with runtimes that don't do that, otherwise import("node:crypto") would also be fine.

In this case the whole reason I'm using esbuild is because require() is technically also ndoejs specific, so I want to avoid using require() and stuff like require.js.

Also this

After esbuild --bundle, the script should be self-contained.

Solving this with a hardcoded require would be undocumented behavior, it would create more issues in the future imo.

[razshare]

I noticed in the compiled code of the reproduction that the only reason crypto is being used here is to generate sha256 strings for dom elements.

So stuff like this

let csp_attr = "";
if (this.global.csp.nonce) {
  csp_attr = ` nonce="${this.global.csp.nonce}"`;
} else if (this.global.csp.hash) {
  const hash = await sha256(body);
  this.global.csp.script_hashes.push(`sha256-${hash}`);
}
return `
<script${csp_attr}>${body}<\/script>`;

May I ask why the choice of importing a platform specific library for this?

Is it because of performance issues? Like js overhead and such?

If that's not an issue, then sha256 could be implemented from scratch in js, it's not that much code.

Unless I'm missing something.

[Conduitry]

What environment are you running this in where the import() function causes a runtime error in CJS code?

[razshare]

Goja https://github.com/dop251/goja.
If you need a full reproduction with Goja I can provide that as well.

However, the issue at hand is getting esbuild to behave like it should, aka inline dependencies, like it did up until version 5.45.10 of svelte.

I need the code inlined for various reasons, for example:

1. It saves me having to embed node_modules, which would be crazy
2. I can warm up the jit compiler on the whole application in advance
3. It's also easier to debug and compare outputs between different versions because I don't have to hop through a file tree to find things

[Conduitry]

node:crypto isn't a dependency that would ever come from from node_modules. Was esbuild previously bundling your app with its own polyfilled version of it? And Goja was previously falling back to this inlined polyfill because it doesn't have the webcrypto API as a crypto global?

[Conduitry]

Oh, were you saying that bundling is necessary because you want to be able to bundle your other dependencies that actually do live in node_modules?

Svelte assuming that, if you're not going to be using one of the blessed runtimes, then you have https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API available sounds like a reasonable requirement in my opinion. And if you do have that, then the import() should never even be reached.

[razshare]

node:crypto isn't a dependency that would ever come from from node_modules.

Yes I understand, I was just explaining why I need the inlining feature since require() came up above.

Was esbuild previously bundling your app with its own polyfilled version of it?

No, there was no import() call in 5.45.10, I can't even find a sha256() function in the final bundle or the crypto.js file in the source code.

Additionally, Goja doesn't implement crypto, as you mentioned, and I'm assuming all those hashes were falling back to an empty string.

then you have https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API available sounds like a reasonable requirement in my opinion.

That's my fix right now, though I'm not using Web Crypto because that's also platform specific.
I'm just using Go's crypto library - https://github.com/razshare/frizzante/blob/63f835c93352a8e284a3e941658d6ed430ee1c1e/internal/project/lib/core/javascript/new_render.go#L67-L85

But before doing any of that I have to get rid of the import() doing shady stuff like this - https://github.com/razshare/frizzante/blob/63f835c93352a8e284a3e941658d6ed430ee1c1e/internal/project/lib/core/ssr/new.go#L41-L46

And if you do have that, then the import() should never even be reached.

My bad, I wasn't clear enough, when I said "it just hits you at runtime when running" what I meant was my program's runtime, as in: it doesn't break esbuild (which I'm running separately to package the script before creating the binary), instead it crashes when I feed the script to Goja because it sees the import().

[razshare]

Oh, were you saying that bundling is necessary because you want to be able to bundle your other dependencies that actually do live in node_modules

Yes exactly, it allows me to create standalone binaries that will run anywhere without any external dependencies as long as Go supports the OS.

[razshare]

I thought about what you said about the runtime not reaching the import() and I was having some doubts myself, but it does in fact crash without ever reaching the import call, I just checked it.

It just fails parsing the script, it sees import as a reserved keyword, but it just rejects it (error is Unexpected reserved word).

I apologize that I'm not familiar with svelte's code base, all I can go on about is the output of the compiler and/or output of esbuild and peek at the source code in specific areas that look related.

However, I did manage to find out a few other things.

So to expand on what you said

Was esbuild previously bundling your app with its own polyfilled version of it?

In version 5.45.10 there doesn't seem to be any sha256() function involved in the final bundle, additionally <script> don't seem to get the nonce treatment they get in later versions.

More specifically in 5.45.10 I can't find anything resembling this

svelte/packages/svelte/src/internal/server/renderer.js

Lines 836 to 847 in 7deedc5

	let csp_attr = '';
	if (this.global.csp.nonce) {
	csp_attr = ` nonce="${this.global.csp.nonce}"`;
	} else if (this.global.csp.hash) {
	// note to future selves: this doesn't need to be optimized with a Map<body, hash>
	// because the it's impossible for identical data to occur multiple times in a single render
	// (this would require the same hydratable key:value pair to be serialized multiple times)
	const hash = await sha256(body);
	this.global.csp.script_hashes.push(`sha256-${hash}`);
	}
	return `\n\t\t<script${csp_attr}>${body}</script>`;

Which seems to be the only place in the whole project where sha256() is being used.

Which checks out with this pr - #17338 , the only PR in https://github.com/sveltejs/svelte/releases/tag/svelte%405.46.0 (the version after 5.45.10).

[razshare]

A quick update on this, I managed to solve the problem without using obfuscated_import() or other weird tricks.

Esbuild supports aliasing through cli, js and go api out of the box - https://esbuild.github.io/api/#alias , so the original #17762 issue can be fixed in userland with something like this

esbuild app.js --bundle --alias:node:crypto=./empty.ts

or in this case, using go

api.Build(api.BuildOptions{
    Bundle: true,
    Format: format,
    Alias:  map[string]{
    	"node:crypto": "./empty.ts",
    },
})

// ./empty.ts
export default {}

This means there's no need to hide import() from esbuild anymore.

This feels less hacky and invasive, more explicit and most importantly it actually generates 1 single file with all dependencies bundled in, no import() calls, no require() calls, just pure js, as it should be when running esbuild --bundle.

What do you think, is it worth reverting the obfuscation changes in favor of documenting the solution on the svelte docs, perhaps with a note or warning of sorts?

Then when the time comes to drop Node 18 just remove the section from the svelte docs.