When an unused function from lodash is imported, building the Vue app with Vite results in a blank page, yet no errors appear in the console.

[hahazexia]

vite-app-import-lodash-circular-reference-issue

vite-app-import-lodash-circular-reference-issue

In the module file for vue-i18n multi-language support, a lodash method is imported with import { floor } from 'lodash';, but this lodash method is not used. After packaging with vite, it is found that tree-shaking does not work, and the entire lodash file is packaged into the final output JS. Moreover, after the vue app starts, the page goes blank, and no error messages are displayed in the browser console. Setting breakpoints in the output files reveals that the multi-language module JS imports the main JS file, and the methods in the main JS file dynamically import this multi-language module JS file, resulting in a circular reference issue.

this is ZH-CN.js , import floor function but not use

import { floor } from 'lodash';
export default {
  content: '内容',
};

this is i18n.js

import { createI18n } from 'vue-i18n';
import { useLocaleStoreWithOut } from './locale';

const createI18nOptions = async () => {
  const localeStore = useLocaleStoreWithOut();
  const locale = localeStore.getCurrentLocale;
  const localeMap = localeStore.getLocaleMap;
  const defaultLocal = await import(`./locales/${locale.lang}.js`);
  const message = defaultLocal.default ?? {};

  return {
    legacy: false,
    locale: locale.lang,
    fallbackLocale: locale.lang,
    messages: {
      [locale.lang]: message,
    },
  };
};

const option = await createI18nOptions();
const i18n = createI18n(option);

export default i18n;

this is main.js

import './assets/main.css';

import { createApp } from 'vue';
import App from './App.vue';
import { store } from './store';
import i18n from './i18n';

const app = createApp(App);
app.use(store);
app.use(i18n);

app.mount('#app');

this code fragment is in vite build main js (dist\assets\index-wFQsXaez.js) :

const createI18nOptions = async () => {
  const localeStore = useLocaleStoreWithOut();
  const locale = localeStore.getCurrentLocale;
  localeStore.getLocaleMap;
  const defaultLocal = await __variableDynamicImportRuntimeHelper(
    /* @__PURE__ */ Object.assign({
      './locales/en.js': () =>
        __vitePreload(
          () => import('./en-DZ0iot4c.js'),
          true ? [] : void 0,
          import.meta.url
        ),
      './locales/zh-CN.js': () =>
        __vitePreload(
          () => import('./zh-CN-bjSBKZ1p.js'),
          true ? [] : void 0,
          import.meta.url
        ),
      './locales/zh-TW.js': () =>
        __vitePreload(
          () => import('./zh-TW-mgeOf5EX.js'),
          true ? [] : void 0,
          import.meta.url
        ),
    }),
    `./locales/${locale.lang}.js`,
    3
  );
  const message = defaultLocal.default ?? {};
  return {
    legacy: false,
    locale: locale.lang,
    fallbackLocale: locale.lang,
    messages: {
      [locale.lang]: message,
    },
  };
};
const option = await createI18nOptions();

this is vite build ZH-CN.js:

import './index-wFQsXaez.js';
const zhCN = {
  contene: '内容',
};
export { zhCN as default };

you can see index-wFQsXaez.js import ZH-CH.js, and ZH-CN.js import index-wFQsXaez.js, there is a circular reference issue.

Is this phenomenon a bug?

[kaminagakur4]

Drop the top-level await from src/i18n.js and do the waiting inside a function. Keep the rest of the file as it is, imports and export default included, and just add:

// i18n.js, alongside what's already there
export const setupI18n = async () => createI18n(await createI18nOptions());

// main.js
import { setupI18n } from './i18n';

const bootstrap = async () => {
  const app = createApp(App);
  app.use(store);
  app.use(await setupI18n());
  app.mount('#app');
};

bootstrap();

That alone fixes the blank page, and you can keep the lodash import exactly where it is.

You've hit two separate problems that happen to look like one.

The blank page

It isn't the circular reference by itself. It's a module deadlock. The entry chunk starts evaluating, reaches const option = await createI18nOptions() and suspends. The dynamic import of the locale begins. The locale chunk's first statement is import "./index-wFQsXaez.js", and because the entry is still in async evaluation, the locale waits on it. The entry is waiting on the locale. Neither promise ever settles, and nothing throws. That's why the page is blank and the console is clean at the same time.

This is plain ESM semantics, not Vite. The same graph with no Vite, no Rollup and no lodash deadlocks in the browser too:

// entry.js
export const shared = 1;
const m = await import('./leaf.js');
console.log('never runs');

// leaf.js
import './entry.js';
export default 42;

In Chrome that hangs silently, same as your app. Node deadlocks on it as well, but it's kinder about it: you get Warning: Detected unsettled top-level await and exit code 13, which is a much faster way to see what's happening.

The tree shaking

lodash 4.17.21 is CommonJS. No "module" field, no "exports" field, one lodash.js, so import { floor } from 'lodash' can't be shaken per specifier.

But note your App.vue also imports lodash and calls floor, so lodash was already in the entry chunk legitimately. The dead line in zh-CN.js doesn't add lodash to the bundle. It makes lodash "shared" between the entry chunk and the locale chunk, and that's what makes Rollup give the locale a static import of the entry. Removing that line changed my bundle size by zero bytes and still fixed the page.

What I measured

Your repro, npm ci so vite 7.1.2 and rollup 4.46.2, node v26, headless Chrome. My build came out byte identical to the dist/ you committed. "Mounted" means #app isn't empty 10 seconds after load.

change	cycle	top-level await	mounted
none, as published	yes	yes	no
drop the dead import in zh-CN.js	no	yes	yes
keep it, drop the TLA	yes	no	yes
import floor from 'lodash/floor'	yes	yes	no
lodash-es in zh-CN.js	no	yes	yes
lodash-es, locale really uses floor	yes	yes	no
same, drop the TLA	yes	no	yes

Blank exactly when the cycle and the top-level await are both present. The console was empty in all seven runs.

Two traps worth knowing. lodash/floor does not fix it: the locale chunk still reaches into the entry for the CommonJS interop helper, import { commonjsGlobal } from "./index-DUJQdf2P.js", so the cycle survives and the page stays blank. And lodash-es only fixes your case because the import is unused there and gets shaken away completely. As soon as a locale file really uses a helper the app also uses, the module is shared again and the blank page comes back.

For the size, lodash-es is worth it but only if you convert both places. It isn't in your lockfile yet, so npm i lodash-es, then switch zh-CN.js and App.vue. Converting only zh-CN.js gave me exactly zero reduction, since App.vue still pulls the CommonJS build in. Doing both took the entry chunk from 501.82 kB to 281.95 kB. Then drop the top-level await for correctness, because that's the part that still holds once the sharing is real.

To your question, the chunking is expected Rollup behavior and the deadlock is standard ESM evaluation, so this isn't a Vite bug. It's a sharp edge of top-level await in an entry chunk. Consistent with that, vite dev renders your unmodified source fine, because dev serves unbundled modules and the locale to entry edge never exists.

[chzaeem47]

I think there are actually two separate issues here: the circular chunk dependency is a consequence of how Rollup has to share the CommonJS lodash module, while the blank page is caused by the combination of that cycle with the top-level await.

The important part is this in i18n.js:

const option = await createI18nOptions();

Your entry chunk starts evaluating and then suspends on the top-level await.

At that point createI18nOptions() dynamically imports the locale:

await import(`./locales/${locale.lang}.js`);

Rollup has put some of the lodash/CommonJS machinery in the entry chunk, so the generated locale chunk ends up containing something equivalent to:

import "./index-wFQsXaez.js";

Now you effectively have:

index chunk
   │
   └── top-level await
          │
          ▼
     locale chunk
          │
          └── imports index chunk

The entry is waiting for the locale to finish, while the locale is waiting for the entry's evaluation to finish. That's a module evaluation deadlock, so the application can remain blank without a normal runtime exception.

A simple way to verify this is to remove the top-level await and perform the async initialization before mounting the app:

// i18n.js
export const setupI18n = async () => {
  const options = await createI18nOptions();
  return createI18n(options);
};

Then:

// main.js
import { createApp } from "vue";
import App from "./App.vue";
import { store } from "./store";
import { setupI18n } from "./i18n";

const bootstrap = async () => {
  const app = createApp(App);

  app.use(store);
  app.use(await setupI18n());

  app.mount("#app");
};

bootstrap();

This keeps the async boundary outside the module's top-level evaluation, so the locale chunk is allowed to load normally.

Regarding this line:

import { floor } from "lodash";

the fact that floor is unused does not necessarily mean the CommonJS lodash package can be tree-shaken like an ESM package. lodash is distributed as CommonJS, so Rollup cannot generally eliminate individual exports in the same way it can with a statically analyzable ESM package.

If you want reliable per-function tree shaking, use an ESM build such as:

npm install lodash-es

and:

import { floor } from "lodash-es";

Or import the function directly:

import floor from "lodash/floor";

But I would treat that as a separate bundle-size improvement rather than the fix for the blank page.

So I don't think the generated:

locale -> index
index  -> locale

relationship by itself proves a Vite bug. Rollup is allowed to create shared-module/chunk dependencies like this. The problematic part is combining that graph with a top-level await that suspends evaluation of the entry module.

The most useful test is:

1. Keep the lodash import.
2. Remove the top-level await.
3. Initialize i18n before app.mount().

If the blank page disappears, that confirms the root cause is the ESM evaluation cycle rather than Vue or the unused lodash import itself.

[ORCHORDS]

kaminagakur4 nailed the module deadlock fix. The lodash piece they did not address is also worth a precise answer.

Two problems in your setup, in order of impact:

1. The blank page is a top-level await module deadlock, not a lodash bug.

The prebundled index.js suspends at const option = await createI18nOptions(). During that suspension, the dynamic-imported locale chunk (zh-CN.js) tries to evaluate, but Rollup rewrote it to import './index-wFQsXaez.js' so it can resolve the shared module graph. The shared graph is the chunk that is suspended. Classic deadlock: A is awaiting B's dynamic import; B is statically importing A; A is suspended, B cannot finish; A cannot resume.

kaminagakur4's fix is correct: move the await into a function. Code:

// i18n.js
import { createI18n } from 'vue-i18n'
import { useLocaleStoreWithOut } from './locale'

export const createI18nOptions = async () => {
  const localeStore = useLocaleStoreWithOut()
  const locale = localeStore.getCurrentLocale
  const localeMap = localeStore.getLocaleMap
  const defaultLocal = await import(`./locales/${locale.lang}.js`)
  const message = defaultLocal.default ?? {}
  return {
    legacy: false,
    locale: locale.lang,
    fallbackLocale: locale.lang,
    messages: { [locale.lang]: message },
  }
}

export const setupI18n = async () => createI18n(await createI18nOptions())

// main.js
import { setupI18n } from './i18n'

const bootstrap = async () => {
  const app = createApp(App)
  app.use(store)
  app.use(await setupI18n())
  app.mount('#app')
}

bootstrap()

This breaks the suspension chain because main.js owns the entry point and no locale chunk tries to import it back.

2. The lodash tree-shaking failure is real, and the fix is mechanical.

import { floor } from 'lodash' imports from the CJS lodash main entry, which exports every function as a property of the same default export. Rollup cannot tree-shake the default export because every helper is on it. That is why your output JS contains all of lodash, not just floor.

Three fixes:

A. Import from the modular lodash subpath:

// instead of: import { floor } from 'lodash'
import floor from 'lodash/floor'
// or
import { floor } from 'lodash-es'

lodash-es is the ESM build of lodash and tree-shakes correctly because each function is its own ESM module. Switching import { floor } from 'lodash' to import { floor } from 'lodash-es' (after installing lodash-es as a dep) fixes the bundle size issue immediately.

B. (If you must keep import { floor } from 'lodash') configure Vite to pre-bundle lodash into its modular ESM equivalent:

// vite.config.ts
export default defineConfig({
  optimizeDeps: {
    include: ['lodash'],
  },
  build: {
    rollupOptions: {
      // tell Rollup to treat lodash's default export as a namespace
      // so named imports tree-shake correctly
      treeshake: 'smallest',
    },
  },
})

This is not a magic bullet. optimizeDeps.include forces Vite's dev pre-bundler to convert lodash to ESM on the fly, which fixes the dev-side resolution but does not change the production bundle path. In production, you need lodash-es.

C. (Cleanest) Drop lodash entirely for floor. It is one function:

const floor = Math.floor

For a single function import there is no reason to take the lodash dependency. Math.floor is identically defined and shipped with every JS runtime.

For your zh-CN.js, none of these change the runtime — the floor import is unused in your snippet, so even the bare import { floor } from 'lodash' in zh-CN.js does nothing at runtime. The bug is purely bundle-size. After applying (A) or (C), the build output's lodash payload drops from ~70KB gzipped to 0 bytes.

Combining both fixes (the deadlock + the lodash tree-shaking) gives you a working app with the correct bundle size. Order of operations:

1. Move top-level await out of i18n.js into a setupI18n() function (kills the blank page).
2. Change import { floor } from 'lodash' to import { floor } from 'lodash-es' in zh-CN.js (kills the bundle bloat).
3. Or just delete the import entirely since it is unused (cleanest).

Cross-references:

• vuejs/core discussion ci: fix playwright cache #11254 (a long thread on top-level await + dynamic imports in production)
• vitejs/vite docs: https://vitejs.dev/guide/features.html#async-chunks (the section explaining why top-level await inside the entry chunk can deadlock)
• lodash docs: https://github.com/lodash/lodash/tree/4.17.21-es (the lodash-es package, ESM build)
• ESBuild pre-bundling docs: https://esbuild.github.io/api/#live-reload--watch-mode (the underlying mechanism in Vite's optimizeDeps)