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

Cannot destructure property 'AsymmetricMatcher' with deps.inline: true #2806

Closed
6 tasks done
Leksat opened this issue Feb 4, 2023 · 21 comments · Fixed by #4815
Closed
6 tasks done

Cannot destructure property 'AsymmetricMatcher' with deps.inline: true #2806

Leksat opened this issue Feb 4, 2023 · 21 comments · Fixed by #4815

Comments

@Leksat
Copy link

Leksat commented Feb 4, 2023

Describe the bug

I found that tests are broken after upgrading vitest from 0.27.1 to 0.28.4

% pnpm test

> test@ test /Users/alex/work/vitest-AsymmetricMatcher-issue
> vitest run --passWithNoTests


 RUN  v0.28.4 /Users/alex/work/vitest-AsymmetricMatcher-issue


 Test Files  no tests
      Tests  no tests
   Start at  15:04:47
   Duration  794ms (transform 242ms, setup 0ms, collect 0ms, tests 0ms)

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Unhandled Errors ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

Vitest caught 1 unhandled error during the test run.
This might cause false positive tests. Resolve unhandled errors to make sure your tests are not affected.

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Unhandled Error ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
TypeError: Cannot destructure property 'AsymmetricMatcher' of '__vite_ssr_import_0__.plugins' as it is undefined.
 ❯ node_modules/.pnpm/@vitest+utils@0.28.4/node_modules/@vitest/utils/dist/index.js:22:3
     20|   AsymmetricMatcher
     21| ];
     22| function stringify(object, maxDepth = 10, { maxLength, ...options } = {}) {
       |   ^
     23|   const MAX_LENGTH = maxLength ?? 1e4;
     24|   let result;
 ❯ VitestRunner.directRequest node_modules/.pnpm/vite-node@0.28.4_@types+node@18.11.18/node_modules/vite-node/dist/client.mjs:312:5
 ❯ VitestRunner.cachedRequest node_modules/.pnpm/vite-node@0.28.4_@types+node@18.11.18/node_modules/vite-node/dist/client.mjs:156:14
 ❯ VitestRunner.dependencyRequest node_modules/.pnpm/vite-node@0.28.4_@types+node@18.11.18/node_modules/vite-node/dist/client.mjs:204:14
 ❯ async /Users/alex/work/vitest-AsymmetricMatcher-issue/node_modules/.pnpm/@vitest+runner@0.28.4/node_modules/@vitest/runner/dist/index.js:3:31
 ❯ VitestRunner.directRequest node_modules/.pnpm/vite-node@0.28.4_@types+node@18.11.18/node_modules/vite-node/dist/client.mjs:312:5
 ❯ VitestRunner.cachedRequest node_modules/.pnpm/vite-node@0.28.4_@types+node@18.11.18/node_modules/vite-node/dist/client.mjs:156:14
 ❯ VitestRunner.dependencyRequest node_modules/.pnpm/vite-node@0.28.4_@types+node@18.11.18/node_modules/vite-node/dist/client.mjs:204:14
 ❯ async /Users/alex/work/vitest-AsymmetricMatcher-issue/node_modules/.pnpm/vitest@0.28.4/node_modules/vitest/dist/entry.js:5:31
 ❯ VitestRunner.directRequest node_modules/.pnpm/vite-node@0.28.4_@types+node@18.11.18/node_modules/vite-node/dist/client.mjs:312:5

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
 ELIFECYCLE  Test failed. See above for more details.

The error is gone if I comment out the deps.inline setting: https://github.com/Leksat/vitest-AsymmetricMatcher-issue/blob/3d77d1d5e4b1e86f49e314234db835656388b0f6/vite.config.ts#L8

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-6a5vwn?file=vite.config.ts (I just added deps.inline: true to the standard example)

Or a minimal reproduction:

git clone git@github.com:Leksat/vitest-AsymmetricMatcher-issue.git
cd vitest-AsymmetricMatcher-issue
pnpm i
pnpm test

System Info

% npx envinfo --system --npmPackages '{vitest,@vitest/*,vite,@vitejs/*}' --binaries --browsers

  System:
    OS: macOS 13.2
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 110.18 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.17.0 - ~/.nvm/versions/node/v16.17.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.17.0/bin/yarn
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.0/bin/npm
  Browsers:
    Safari: 16.3
  npmPackages:
    vite: 4.1.1 => 4.1.1
    vitest: 0.28.4 => 0.28.4

Used Package Manager

pnpm

Validations

@treardon17
Copy link

I also have this issue when setting it to true, but using an array of packages to inline seems to work. I know that might not fit every use case, but it resolved my issue.

ex:

{
  deps: {
    inline: ['vuetify']
  }
}

@Vithanco
Copy link

Vithanco commented Mar 4, 2023

+1

lihbr added a commit to prismicio/slice-machine that referenced this issue Mar 14, 2023
This prevents vitest-dev/vitest#2806 which is broken in the latest version of vitest for now
@Leksat
Copy link
Author

Leksat commented Mar 17, 2023

Found a workaround: inline everything except for vitest deps.

  {
    deps: {
      inline:
        // TODO: Replace with true once https://github.com/vitest-dev/vitest/issues/2806 is fixed.
        [/^(?!.*vitest).*$/],
    },
  },

@Vithanco
Copy link

Actually, I just commented the whole inline out and it works.

  test: {
    // deps: {
    //   inline: true
    // }
  },

@natew
Copy link

natew commented Apr 7, 2023

Tamagui monorepo stuck on 0.27 due to this, you can pretty easily clone and yarn up vitest and then yarn test to replicate:

https://github.com/tamagui/tamagui

@Tanimodori
Copy link
Contributor

Tanimodori commented Apr 27, 2023

I've tested this issue with various vitest releases and find out that 0.27.3 works while 0.28.0 doesn't. The only possible change made between them is the merge of #2721 done in 482b72f , which:

  • moves test runner into a separate package
  • stops shipping @vitest/* packages along with Vitest
  • allows disabling auto inlining of the Vitest package

But the default inlining conifg of inline: true doesn't updates with this merge:

const extraInlineDeps = [
/^(?!.*(?:node_modules)).*\.mjs$/,
/^(?!.*(?:node_modules)).*\.cjs\.js$/,
// Vite client
/vite\w*\/dist\/client\/env.mjs/,
// Nuxt
'@nuxt/test-utils',
]

So when run with inline: true the runner failed to find vitest util packages as they are not shipped with vitest now nor are they inlined with the default extraInlineDeps array.

It should add @vitest/* packages when inlining as @Leksat said:

const extraInlineDeps = [
  /^(?!.*(?:node_modules)).*\.mjs$/,
  /^(?!.*(?:node_modules)).*\.cjs\.js$/,
  // Vite client
  /vite\w*\/dist\/client\/env.mjs/,
  // Nuxt
  '@nuxt/test-utils',
+  // @vitest packages due to #2721
+  [/^(?!.*vitest).*$/],
]

Maybe this regex is too board and need to be narrowed down, but the smoking gun of this issue is here.

@sheremet-va
Copy link
Member

sheremet-va commented Apr 27, 2023

Maybe this regex is too board and need to be narrowed down, but the smoking gun of this issue is here.

I disagree. It should not be needed to inline Vitest at all.

It should not be needed to inline any dependency to be honest. One of the reason why it takes so long to fix is because we will introduce another way to fix dependency issues and this usage of inline will probably be deprecated.

The fact that we allow true as a value was just to align with Vite‘s noExternal and should probably never be actually used. If you are using inline: true, you are shooting yourself in the foot.

@Tanimodori
Copy link
Contributor

Tanimodori commented Apr 27, 2023

@sheremet-va Sorry for my misunderstanding. So I reorganized timeline which appears to be:

  • deps.inline is introduced to solve esm-only script issues.
  • feat!: move test runner into a separate package #2721 is introduced. inline: true no longer works as stated above.
  • deps.inline changed the default to [].
  • We will find another way to solve esm script issue so deps.inline may become deprecated then.

So I guess we should avoid using deps.inline as long as the root issue don't occur before the root issue is fixed here.

@dagnym
Copy link

dagnym commented May 11, 2023

this needs to be fixed.

@sheremet-va
Copy link
Member

Please, consider using deps.experimentalOptimizer instead of deps.inline.

deps.inline will be deprecated in future versions and will not be shipped in Vitest 1.0.

@danielroe
Copy link
Contributor

@sheremet-va We currently need to perform transforms on code within node_modules when using vitest with Nuxt. (For example, some of the code shipped within node_modules is 'runtime' code that references build-time aliases.) What's the best way to configure this using the new experimentalOptimizer?

@sheremet-va
Copy link
Member

sheremet-va commented Jun 2, 2023

@sheremet-va We currently need to perform transforms on code within node_modules when using vitest with Nuxt. (For example, some of the code shipped within node_modules is 'runtime' code that references build-time aliases.) What's the best way to configure this using the new experimentalOptimizer?

optimizer inherits options from optimizeDeps, so if dependency is already there it should work out of the box. But instead of crawling imports, it optimizes only dependencies inside experimentalOptimizer.include or optimizeDeps.include.

@danielroe
Copy link
Contributor

danielroe commented Jun 12, 2023

@sheremet-va With 0.32.0, vitest-environment-nuxt now fails on imports from virtual files.

I haven't yet dived in to see what the issue is, but it feels like it might be related (?).

@sheremet-va
Copy link
Member

sheremet-va commented Jun 13, 2023

fails on imports from virtual files

Do you use deps.inline: true?

Your issue probably happens because of this: #3544

@danielroe
Copy link
Contributor

No, we specify dependencies to inline by name/regexp. That certainly looks like the issue to track - thank you. ❤️

@ant-dep
Copy link

ant-dep commented Jun 18, 2023

I got TypeError: Unknown file extension ".css" for [my-project]/node_modules\@react-spectrum\actiongroup\dist\main.css when running tests that import a component that is importing "@adobe/react-spectrum"

deps.inline doesn't work and I'm almost losing faith after multiple hours of trying either to exclude or inlude this dependency

@sheremet-va
Copy link
Member

deps.inline doesn't work and I'm almost losing faith after multiple hours of trying either to exclude or inlude this dependency

deps.inline is a simple filepath check. In your case, to include a file, you need to add @react-spectrum/actiongroup

@ant-dep
Copy link

ant-dep commented Jun 19, 2023

Where do I need to add this ?
because if you refer to deps.inline, I tried multiple things that don't work like :
deps: {
inline: ['@react-spectrum']
},
deps: {
inline: ['@react-spectrum/datepicker']
},
deps: {
inline: ['@react-spectrum', '@react-spectrum/datepicker', 'intl-messageformat']
},

@ant-dep
Copy link

ant-dep commented Jun 20, 2023

Update: I removed @react-spectrum and change my InputDate with native function. Problem fixed :)

@mattiaz9
Copy link

I don't use the inline option but i still get the error: Cannot destructure property 'AsymmetricMatcher' of '__vite_ssr_import_0__.plugins' as it is undefined.

I tried using this trick but it didn't work for me:

  {
    deps: {
      inline:
        // TODO: Replace with true once https://github.com/vitest-dev/vitest/issues/2806 is fixed.
        [/^(?!.*vitest).*$/],
    },
  },

I'm not sure if this could be related but I only noticed this error after switching to an Apple Silicon Mac

@davidmyersdev
Copy link
Contributor

This can also happen when using the ssr.noExternal option in Vite. The following config produced the above error.

export default defineConfig({
  ssr: {
    noExternal: /.*/,
  },
})

I was able to fix it by excluding Vite:

export default defineConfig({
  ssr: {
    noExternal: /^(?!.*\/vitest\/).*$/,
  },
})

@github-actions github-actions bot locked and limited conversation to collaborators Jan 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.