Repository navigation
Bundled dev: Phase 1 feedbacks #22747
Replies: 7 comments 7 replies
|
Hi. I get the The repo is open source, but it's not a minimal reproduction, though. Just in case the Vite team wants some quick feedback. Here is the steps to reproduce: I got the following error in the browser console: 
|
|
Thanks Vite team for working on this! When trying it out, I'm getting a // myFile.ts
import {
getCompanySupplierInvoicesQueryKey,
getCountSummaryCompanySupplierInvoicesQueryKey,
} from 'queries/supplierInvoices'
// queries/supplierInvoices.js
export const getCompanySupplierInvoicesQueryKey = (parameters) => {
return parameters ? ['getCompanySupplierInvoices', parameters] : ['getCompanySupplierInvoices']
}
// [MISSING_EXPORT] "getCompanySupplierInvoicesQueryKey" is not exported by "queries/supplierInvoices.js?rolldown-lazy=1".
// ╭─[ myFile.ts:2:10 ]
// │
// 2 │ import { getCompanySupplierInvoicesQueryKey } from "queries/supplierInvoices";
// │ ─────────────────┬────────────────
// │ ╰────────────────── Missing export |
|
Has the team discussed potential options to support backend integrations like Rails or Laravel? Those typically depend on a written manifest, which might be too costly to regenerate every time a file changes. As an alternative, the Vite dev server could provide an API that allows to obtain the necessary information for an entrypoint. For context: |
|
I thought about it once but forgot to put it in the road map.
I guess the information for the entrypoint itself isn't hard, but the part of waiting the bundle to success. vite/packages/vite/src/node/server/middlewares/indexHtml.ts Lines 467 to 500 in 092cb3b |
|
hello, we're having the following error, not sure how to fix it |
|
Thanks for adding this! One issue that's blocking my team from implementing this is that this feature does not respect the value of |
|
First off — we've been testing One observation from a minimal fixture that seems to contradict the Phase 3 audit's "css/scss/css-modules all HMR correctly" note, and I'd like to understand whether it's expected for released 8.1.x: Observed: with Suspected reconciliation: Repro (5 files, no framework, no plugins): // package.json
{ "name": "repro", "type": "module", "scripts": { "dev": "vite" }, "devDependencies": { "vite": "8.1.5" } }// vite.config.js
import { defineConfig } from "vite";
export default defineConfig({ experimental: { bundledDev: true } });<!-- index.html -->
<!doctype html><html><body><div id="app"></div><script type="module" src="/src/main.js"></script></body></html>// src/main.js
import "./style.css";
document.getElementById("app").textContent = "v1";/* src/style.css */
body { background: rgb(1, 1, 1); }Steps:
Questions:
Context for why we care about the distinction: we're rolling bundledDev out behind a flag to a large user base, and "every style tweak = full page reload" vs "CSS hot updates work" changes which cohorts we can include before the Phase 2 line lands. Happy to test nightlies/pkg.pr.new builds of #22956 against our real templates (React + TanStack Start) and report back. |
|
I could not reproduce this. On the exact pin you used, 
The frame is const { updateStyle: __vite__updateStyle, removeStyle: __vite__removeStyle } = import.meta.hot._internal
const __vite__id = ".../style.css"
const __vite__css = "body { background: rgb(1, 1, 1); }"
__vite__updateStyle(__vite__id, __vite__css)
import.meta.hot.accept()
import.meta.hot.prune(() => __vite__removeStyle(__vite__id))The CSS module is its own HMR boundary, and the patch is therefore a JS patch. Your fixture plus its neighbours, the same files measured in both modes:
The fixture behind the tableAll four cases in one Vite root. Run it twice, once with the config and once without, to get both columns. // vite.config.js
import { defineConfig } from 'vite';
export default defineConfig({ experimental: { bundledDev: true } });<!-- index.html -->
<!doctype html>
<html>
<head>
<link rel="stylesheet" href="/src/linked.css" />
</head>
<body>
<div id="app"></div>
<script type="module" src="/src/main.js"></script>
</body>
</html>// src/main.js
import './style.css';
import styles from './mod.module.css';
const el = document.getElementById('app');
el.textContent = 'v1';
el.className = styles.box;/* src/style.css */
body { background: rgb(1, 1, 1); }
/* src/linked.css */
#app { border-width: 1px; border-style: solid; }
/* src/mod.module.css */
.box { color: rgb(10, 10, 10); }Edit one file per case and watch the frames: the |
|
You're right, and thank you for the thorough repro + the |
|
(RESOLVED) Added - env.mjs:8 Uncaught ReferenceError: __DEFINES__ is not definedin the browser console. No errors in the terminal. |
|
It seems that
|
|
This may fix your problem #23664. We need to have an internal discussion about this feature. |
|
With this stack of PR here, the issue above will very likely be resolved. Due to the limitations, I'm not able to cut a preview release. Would you try it out locally and keep me posted? |
|
It works! I used a preview from the latest commit available: "resolutions": {
"vite": "https://pkg.pr.new/vite@8a4c19c"
}, |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
We're opening a discussion to gather feedback about this feature for the phase 1.
Note
Phase 1 focuses on the browser side and the basic plugins and the main features. If you are using a third party plugin, it may not work with this mode. If you are using a minor feature, it may not work as well. We are working on expanding the support and preparing a document that clarifies the changes that may be needed on the plugin side. See Bundled dev mode design doc and Road Map for more details.
All reactions