Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V3 breaks dynamic imports #7361

Open
6 tasks done
Jason3S opened this issue Jan 26, 2025 · 1 comment · May be fixed by #7365
Open
6 tasks done

V3 breaks dynamic imports #7361

Jason3S opened this issue Jan 26, 2025 · 1 comment · May be fixed by #7365
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)

Comments

@Jason3S
Copy link

Jason3S commented Jan 26, 2025

Describe the bug

V3 seems to be changing how dynamic imports work.

Imports in the following style seem to be incorrectly cached.

const lib = await import('<url#hash1>');
// ...
const libUpdated = await import('<url#hash2>');
assert(lib !== libUpdated);

Note: This works correctly in V2.

Might be related to: #7269, #7266, but it doesn't seem to be fixed in v3.0.4.

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-1rbfzzpd?file=test%2Fsuite.test.ts

describe('suite name', () => {
  it('validates that async import works as expected.', async () => {
    const hello0 = await import(urlHelloJs.href);
    expect(hello0['sayHello']).toBeTypeOf('function');
  });

  it('validates that async import with hash change will reload.', async () => {
    const hello0 = await import(urlHelloJs.href);
    const url1 = new URL(urlHelloJs);
    url1.hash = 'bustCache=1';
    const hello1 = await import(url1.href);
    expect(hello1['sayHello']).toBeTypeOf('function');
    expect(hello1).not.toBe(hello0);
  });

  it('validates that async import with query change will reload.', async () => {
    const hello0 = await import(urlHelloJs.href);
    const url1 = new URL(urlHelloJs);
    url1.searchParams.set('bustCache', '1');
    const hello1 = await import(url1.href);
    expect(hello1['sayHello']).toBeTypeOf('function');
    expect(hello1).not.toBe(hello0);
  });
});

System Info

Note: it breaks on Linux and Windows as well.

  System:
    OS: macOS 15.2
    CPU: (12) arm64 Apple M3 Pro
    Memory: 182.05 MB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.18.1 - ~/.nvm/versions/node/v20.18.1/bin/node
    npm: 10.8.2 - ~/.nvm/versions/node/v20.18.1/bin/npm
    pnpm: 9.15.0 - ~/.nvm/versions/node/v20.18.1/bin/pnpm
  Browsers:
    Chrome: 132.0.6834.110
    Edge: 132.0.2957.127
    Safari: 18.2
  npmPackages:
    @vitest/coverage-istanbul: ^3.0.4 => 3.0.4 
    vite: ^6.0.11 => 6.0.11 
    vitest: ^3.0.4 => 3.0.4

Used Package Manager

pnpm

Validations

@hi-ogawa
Copy link
Contributor

hi-ogawa commented Jan 27, 2025

This looks like a regression from #7087. I just found out fileURLToPath strips them off:

> url.fileURLToPath("file:///hello.js#x=y")
'/hello.js'
> url.fileURLToPath("file:///hello.js?x=y")
'/hello.js'

Side note: Vite doesn't seem to have a same issue even though they also use fileURLToPath internally. This is probably because the module cache key is based on id/url before fileURLToPath normalization. (Oh wait, they do have a same issue https://stackblitz.com/edit/vitest-dev-vitest-fchdscfz?file=repro.js but I imagine the issue is independent from Vitest.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants