Code splitting split out same file imported with different queries

[overlookmotel]

A small optimization on code splitting...

Input:

// src/entry1.js
import x from './shared.mjs?1';
x();

// src/entry2.js
import x from './shared.mjs?2';
x();

// src/shared.js
export default () => console.log('hello!');

With code splitting enabled, this outputs:

// entry1.js
var shared_default = () => console.log("hello!");
shared_default();

// entry2.js
var shared_default = () => console.log("hello!");
shared_default();

This does behave same as the source, so it's correct. But wouldn't it be more efficient to split () => console.log('hello!') into a shared chunk and import it twice with different queries, as in the source?

This is a pretty niche case, so understand if it's not worth the trouble/complexity to implement this optimization.

[evanw]

Isn't this similar to the issue you just filed (#928)? These two modules have separate identity due to different query parameters and should not be considered the same file.

[overlookmotel]

Yes, they are related. Creating only 1 shared chunk but importing it with different queries would be a different way to fix #928.

Having thought about it further, it probably makes little practical difference in the browser. With the import queries approach, you'd get less bytes of code output in total, but browser would still make 2 HTTP requests for chunk-XXX.js?1 and ?2 and cache them separately.

In Node, I suppose it could be a little more efficient as file could be read from disc once instead of twice.

But, anyway, it's small beer. Feel free to close this.

[evanw]

Creating only 1 shared chunk but importing it with different queries would be a different way to fix #928.

Ah, I see what you mean. It doesn't seem like a good idea to me to require that all consumers of esbuild's output are able to understand and discard query parameters. The output is used in many JavaScript engines, not just in the browser and node, and I have a strong hunch that some of them don't support query parameters. So I'm going to close this in favor of the hash change approach.

[overlookmotel]

Yes, that makes sense. Import queries also wouldn't work in CommonJS, when that's supported.