[🐞] build.client doesn't care about previous chunks when the update of the app. #7226
Comments
genki
added
STATUS-1: needs triage
|
Hi @genki with the same code the hash should remain the same. If not we need to figure out the why. If you need to preserve the old chunks too you can implement a Vite plugin that read and write them somewhere to preserve them during builds. Btw this could be a Qwik community plugin. |
|
Another solution cloud be: a Vite plugin that download all the current chunks locally ( based on q-manifest ) and merge them after the build process |
|
@gioboa Thank you for the answer. I wonder why the change happens to q-manifest.json and chunks even if no updates in my source code. Of course, no dynamic There are many chunks built, but most of them are very small and only consists of imports other chunks and one export like this. import"./q-CLq9cP0Z.js";import{c as N}from"./q-TmSm9_Ab.js";import"./q-iUhm9qIU.js";import"./q-CDfZr0w7.js";import"./q-BVGg7BBr.js";import"./q-CT7XUfUO.js";export{N as s_BdTzVN1StNM};And these chunks that are imported here are also changed while the build 1 and 2. As I understood this is something wrong I would investigate more. |
|
Ah, I have one more question. Such the piles of small code snippets that are consist of only imports and one export is expected behaviour?. I don't provide any customization to rollup options. |
|
Here is my const WIDTHS = [640, 1024];
export default defineConfig(():UserConfig => {
return {
plugins: [
qwikCity(),
qwikVite(),
tsconfigPaths(),
],
ssr: {
external: ['node:async_hooks'],
},
preview: {
headers: {
"Cache-Control": "public, max-age=600",
"X-Content-Type-Options": "nosniff",
},
},
resolve: {
alias: {
"~": path.resolve(__dirname, "src"),
},
},
css: {
preprocessorOptions: {
sass: {
additionalData: `$widths: ${WIDTHS.map(w => w + "px").join(",")}\n`,
},
},
},
};
}); |
|
I guess so, can you try to create a small reproduction repo to figure out the situation and solve the issue please? |
|
@gioboa Yeah, I think so too. I have tried with no luck. If get success, I will come back :) |
|
Further investigation about the output, I found the cyclic import between Chunk: const RouteStateContext = /* @__PURE__ */ createContextId("qc-s");
const ContentContext = /* @__PURE__ */ createContextId("qc-c");
const ContentInternalContext = /* @__PURE__ */ createContextId("qc-ic");
const DocumentHeadContext = /* @__PURE__ */ createContextId("qc-h");
const RouteLocationContext = /* @__PURE__ */ createContextId("qc-l");
const RouteNavigateContext = /* @__PURE__ */ createContextId("qc-n");
const RouteActionContext = /* @__PURE__ */ createContextId("qc-a");
const RouteInternalContext = /* @__PURE__ */ createContextId("qc-ir");
const RoutePreventNavigateContext = /* @__PURE__ */ createContextId("qc-p");
const spaInit = eventQrl(/* @__PURE__ */ qrl(() => __vitePreload(() => import("./q-4Y1X7MJF.js"), true ? [] : void 0), "s_o0fE7sdgJro"));
const RouterOutlet = /* @__PURE__ */ componentQrl(/* @__PURE__ */ qrl(() => __vitePreload(() => import("./q-C6SJWZkU.js"), true ? [] : void 0), "s_0rmCF5rEoas"));The last line dynamic imports the RouterOutlet. The imported code is importing it back circulary at the 1st line. Chunk: import { B as spaInit, d as ContentInternalContext } from "./q-D9K9vuh1.js";
import { a as useServerData, C as _jsxBranch, u as useContext, l as _jsxC, f as _jsxQ, p as _qrlSync, F as Fragment, D as SkipRender } from "./q-Bf_tcDXr.js";
const s_0rmCF5rEoas = () => {
const serverData = useServerData("containerAttributes");
if (!serverData) throw new Error("PrefetchServiceWorker component must be rendered on the server.");
_jsxBranch();
const context = useContext(ContentInternalContext);
if (context.value && context.value.length > 0) {
const contentsLen = context.value.length;
let cmp = null;
for (let i = contentsLen - 1; i >= 0; i--) if (context.value[i].default) cmp = _jsxC(context.value[i].default, {
children: cmp
}, 1, "Ms_0");
return /* @__PURE__ */ _jsxC(Fragment, {
children: [
cmp,
/* @__PURE__ */ _jsxQ("script", {
"document:onQCInit$": spaInit,
"document:onQInit$": _qrlSync(() => {
((w, h) => {
var _a;
if (!w._qcs && h.scrollRestoration === "manual") {
w._qcs = true;
const s = (_a = h.state) == null ? void 0 : _a._qCityScroll;
if (s) w.scrollTo(s.x, s.y);
document.dispatchEvent(new Event("qcinit"));
}
})(window, history);
}, '()=>{((w,h)=>{if(!w._qcs&&h.scrollRestoration==="manual"){w._qcs=true;const s=h.state?._qCityScroll;if(s){w.scrollTo(s.x,s.y);}document.dispatchEvent(new Event("qcinit"));}})(window,history);}')
}, null, null, 2, "Ms_1")
]
}, 1, "Ms_2");
}
return SkipRender;
};
export {
s_0rmCF5rEoas
};At least those two chunks can't be exist stably because the hash can't be computed. I guess the Vite would probably roughly solve this deadlock by choosing a random hash for such the chunks. |
|
The why only the larger app cause this issue is maybe those two chunks are not splitted in a smaller apps. |
|
Relating to vitejs/vite#10636 |
We definitely need to solve this cc @wmertens |
|
@gioboa @wmertens But finally, I have found the threshold of the fail and success. Alas, the nonce is random value. |
|
At any rate, the nonce is not the only reason of this issue. |
|
I wrote a vite pluting that merges previous build into import type {Plugin} from 'vite';
import fs from 'fs';
import path from 'path';
const CUR_BUILD = path.resolve(process.cwd(), 'current');
type Options = {
expireDuration?: number; // in seconds
}
export function mergeBuild({expireDuration}:Options = {}): Plugin {
const now = Date.now();
let count = 0;
let size = 0;
return {
name: 'merge-build',
enforce: 'pre',
generateBundle: {
order: "pre",
handler() {
console.log('merge-build copying files...');
const dist = path.resolve(process.cwd(), 'dist');
if (!fs.existsSync(dist)) fs.mkdirSync(dist);
const distBuild = path.resolve(dist, 'build');
if (!fs.existsSync(distBuild)) fs.mkdirSync(distBuild);
// copy current build into distBuild dir wiout change ctime/mtime
const curBuild = fs.readdirSync(CUR_BUILD);
for (const file of curBuild) {
const src = path.resolve(CUR_BUILD, file);
const dst = path.resolve(distBuild, file);
if (fs.existsSync(dst)) continue;
const stats = fs.statSync(src);
// check if file is not expired
if (expireDuration !== undefined) {
if (now - stats.mtimeMs > expireDuration * 1000) continue;
}
fs.copyFileSync(src, dst);
// copy ctime/mtime
fs.utimesSync(dst, stats.atime, stats.mtime);
count++;
size += stats.size;
}
}
},
closeBundle() {
const prettySize = (size / 1024).toFixed(2) + 'kB';
console.log("merge-build:", count, "files", prettySize,
"merged from previous build");
}
};
} |
|
Thanks, that's nice 🥳 |
|
Sorry I am not good at natural languages other than Japanese. |
|
Ok, can you try to modify the plugin to work on CI/CD pipeline env? ( reading and fetching the production chunks ) |
|
@gioboa |
|
Wow good research in this issue. Another thing that changes the hashes is terser, because it picks variable names based on frequency, which changes a lot of code. In vite 6 you can now configure terser to use a static set. |
That's a good idea, is there a free service we can add at that example? |
|
@gioboa I too wanted to know the free storage. @wmertens Indeed. I think the root of this problem is misunderstand about the dynamic import. const {...} = await import(`/name_of_module`) |
Well, Vite 6 is out so let try to fix this problem |
|
@gioboa Is Qwik is ready to be used with the Vite@6? The package.json is pointing to Vite@5. |
Yep, it's working fine with Vite v6 🚀 |
|
I think is this one build terser I found this from terser repo |
|
@gioboa Thanks! I will check it out :) |
|
Finally, I could add the reproduction. |
|
I think there is unexpected randomness in the building process. 5377,5378c5377,5378
< s_VKFlAWJuVm8 as x,
< s_B0lqk5IDDy4 as y,
---
> s_B0lqk5IDDy4 as x,
> s_VKFlAWJuVm8 as y,the order of symbols is different. There can be the unconscious race conditions in the vite/rollup? |
Which component is affected?
Qwik Rollup / Vite plugin
Describe the bug
I am writing somewhat large app with Qwik and when I tried to update it, the
pnpm run build.clientgenerates about 500-600 chunks but they have almost different hash from the previous output.When I would take a rolling update of the app, the existing app running in the browser experiences failure of dynamic import against the previous chunks, because they are no longer exist at that place after the update.
I wanted to make the experience seamless during the app update.
How can I include the previous chunks into the newly generated ones and merge the newer and older
q-manifest?[Updated] I added a reproduction.
Reproduction
https://github.com/genki/qwik-test/tree/fragile_hash_test
Steps to reproduce
Please clone the repo above and install packages then run many times (I expect 10〜20 times)
Please looking into the hash of the last chunk, the largest file.
Because of this reproduction is very smaller than the real case, the result is mostly same hash.
But sometimes it changes, even if no code change has included.
I have attached the case of generated different bundle at under the
./tmphttps://github.com/genki/qwik-test/tree/fragile_hash_test/tmp
Those 2 files are the largest chunks from different 2 builds that are from the same source without any modification.
They are mostly same, but there are small diff like this:
System Info
System: OS: macOS 14.6.1 CPU: (8) arm64 Apple M2 Memory: 75.95 MB / 24.00 GB Shell: 3.6.1 - /opt/homebrew/bin/fish Binaries: Node: 20.18.1 - /opt/homebrew/opt/node@20/bin/node Yarn: 1.22.19 - /opt/homebrew/bin/yarn npm: 9.9.4 - ~/project/jotter/node_modules/.bin/npm pnpm: 9.11.0 - /opt/homebrew/bin/pnpm bun: 1.1.26 - ~/.bun/bin/bun Browsers: Chrome: 131.0.6778.205 Safari: 17.6 npmPackages: @builder.io/qwik: file:../clone/qwik/packages/qwik => 1.10.0 @builder.io/qwik-city: file:../clone/qwik/packages/qwik-city => 1.10.0 typescript: ^5.4.5 => 5.4.5 undici: ^5.28.4 => 5.28.4 vite: ^5.4.11 => 5.4.11Additional Information
In addition, when the app size is larger, the
pnpm run build.clientgenerates almost different hashes even if there's no changes in the source code. Is this expected behaviour?The text was updated successfully, but these errors were encountered: