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

linked dependency causes tests to fail #4032

Open
6 tasks done
ArloL opened this issue Aug 28, 2023 · 13 comments
Open
6 tasks done

linked dependency causes tests to fail #4032

ArloL opened this issue Aug 28, 2023 · 13 comments
Labels
p2-edge-case Bug, but has workaround or limited in scope (priority)

Comments

@ArloL
Copy link

ArloL commented Aug 28, 2023

Describe the bug

Thanks so much for creating such wonderful tooling :)

I believe I have found a bug and hope I can describe it well enough here:

  • a library project that has @mui/base as a dependency and exports files using it
  • a test project that uses the library and has tests executed via vitest
  • hook the library into the test project via a file: resolution and the tests pass ✅
  • hook the library into the test project via a link: resolution and the tests fail with this error message ❌:
yarn run v1.22.19
$ vitest run

 RUN  v0.34.3 /Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project

stderr | src/Test.test.jsx > renders a button
Warning: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem.
Warning: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem.
Error: Uncaught [TypeError: Cannot read properties of null (reading 'useRef')]
    at reportException (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/helpers/runtime-script-errors.js:66:24)
    at innerInvokeEventListeners (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:353:9)
    at invokeEventListeners (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:286:3)
    at HTMLUnknownElementImpl._dispatch (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:233:9)
    at HTMLUnknownElementImpl.dispatchEvent (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:104:17)
    at HTMLUnknownElement.dispatchEvent (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/generated/EventTarget.js:241:34)
    at Object.invokeGuardedCallbackDev (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:4213:16)
    at invokeGuardedCallback (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:4277:31)
    at beginWork$1 (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:27451:7)
    at performUnitOfWork (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:26560:12) TypeError: Cannot read properties of null (reading 'useRef')
    at Object.useRef (/Users/aokeeffe/Developer/vitest-link-reproduction/node_modules/react/cjs/react.development.js:1630:21)
    at Button (/Users/aokeeffe/Developer/vitest-link-reproduction/node_modules/@mui/base/node/Button/Button.js:54:27)
    at renderWithHooks (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:16305:18)
    at updateForwardRef (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:19226:20)
    at beginWork (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:21636:16)
    at HTMLUnknownElement.callCallback (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:4164:14)
    at HTMLUnknownElement.callTheUserObjectsOperation (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/generated/EventListener.js:26:30)
    at innerInvokeEventListeners (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:350:25)
    at invokeEventListeners (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:286:3)
    at HTMLUnknownElementImpl._dispatch (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:233:9)
Warning: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem.
Warning: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem.
Error: Uncaught [TypeError: Cannot read properties of null (reading 'useRef')]
    at reportException (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/helpers/runtime-script-errors.js:66:24)
    at innerInvokeEventListeners (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:353:9)
    at invokeEventListeners (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:286:3)
    at HTMLUnknownElementImpl._dispatch (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:233:9)
    at HTMLUnknownElementImpl.dispatchEvent (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:104:17)
    at HTMLUnknownElement.dispatchEvent (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/generated/EventTarget.js:241:34)
    at Object.invokeGuardedCallbackDev (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:4213:16)
    at invokeGuardedCallback (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:4277:31)
    at beginWork$1 (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:27451:7)
    at performUnitOfWork (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:26560:12) TypeError: Cannot read properties of null (reading 'useRef')
    at Object.useRef (/Users/aokeeffe/Developer/vitest-link-reproduction/node_modules/react/cjs/react.development.js:1630:21)
    at Button (/Users/aokeeffe/Developer/vitest-link-reproduction/node_modules/@mui/base/node/Button/Button.js:54:27)
    at renderWithHooks (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:16305:18)
    at updateForwardRef (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:19226:20)
    at beginWork (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:21636:16)
    at HTMLUnknownElement.callCallback (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/react-dom/cjs/react-dom.development.js:4164:14)
    at HTMLUnknownElement.callTheUserObjectsOperation (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/generated/EventListener.js:26:30)
    at innerInvokeEventListeners (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:350:25)
    at invokeEventListeners (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:286:3)
    at HTMLUnknownElementImpl._dispatch (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/vite-project/node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:233:9)
The above error occurred in the <ForwardRef(Button)> component:

    at Button (/Users/aokeeffe/Developer/vitest-link-reproduction/node_modules/@mui/base/node/Button/Button.js:47:7)
    at p (/Users/aokeeffe/Developer/vitest-link-reproduction/test-projects/workaround-package/dist/vitest-link-reproduction.js:7:24)

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries.

 ❯ src/Test.test.jsx (1)
   × renders a button

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

 FAIL  src/Test.test.jsx > renders a button
TypeError: Cannot read properties of null (reading 'useRef')
 ❯ Object.useRef ../../node_modules/react/cjs/react.development.js:1630:21
 ❯ Button ../../node_modules/@mui/base/node/Button/Button.js:54:27
 ❯ renderWithHooks node_modules/react-dom/cjs/react-dom.development.js:16305:18
 ❯ updateForwardRef node_modules/react-dom/cjs/react-dom.development.js:19226:20
 ❯ beginWork node_modules/react-dom/cjs/react-dom.development.js:21636:16
 ❯ beginWork$1 node_modules/react-dom/cjs/react-dom.development.js:27426:14
 ❯ performUnitOfWork node_modules/react-dom/cjs/react-dom.development.js:26560:12
 ❯ workLoopSync node_modules/react-dom/cjs/react-dom.development.js:26466:5
 ❯ renderRootSync node_modules/react-dom/cjs/react-dom.development.js:26434:7
 ❯ recoverFromConcurrentError node_modules/react-dom/cjs/react-dom.development.js:25850:20

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯

 Test Files  1 failed (1)
      Tests  1 failed (1)
   Start at  11:02:28
   Duration  1.28s (transform 26ms, setup 0ms, collect 437ms, tests 16ms, environment 635ms, prepare 74ms)

error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

From my understanding there should be no difference between these two scenarios and the tests should pass. Please let me know if I can provide more info to make it clearer :)

Reproduction

https://github.com/ArloL/vitest-link-reproduction

System Info

System:
  OS: macOS 13.5.1
  CPU: (10) arm64 Apple M1 Pro
  Memory: 364.38 MB / 16.00 GB
  Shell: 5.9 - /bin/zsh
Binaries:
  Node: 20.5.1 - /opt/homebrew/bin/node
  Yarn: 1.22.19 - /opt/homebrew/bin/yarn
  npm: 9.8.0 - /opt/homebrew/bin/npm
Browsers:
  Safari: 16.6
npmPackages:
  @vitejs/plugin-react: ^4.0.0 => 4.0.4 
  vite: ^4.1.4 => 4.4.9

Used Package Manager

yarn

Validations

@AriPerkkio
Copy link
Member

I've run into this same error when using Jest and linking local NPM packages which have react as dependency. The linked packages were bringing their own copy of React into the runtime. In Jest the solution was to configure moduleNameMapper to resolve react to a single location every time. Maybe Vite's resolve could be configured to do the same? This is something that should be done by user, not in Vitest itself.

This issue may have some examples facebook/react#13991.

@sheremet-va
Copy link
Member

Maybe resolve.dedupe can help?

https://vitejs.dev/config/shared-options.html#resolve-dedupe

@ArloL
Copy link
Author

ArloL commented Aug 30, 2023

Thanks for the suggestions ☺️ I just tried adding the resolve.dedupe setting - hopefully I got it right:
ArloL/vitest-link-reproduction@63e2573

Sadly it did not make the tests pass. Did I maybe add it in the wrong section?

What I find interesting is that there is literally no node_modules in the linked dependency and so I kind of don't know how the second react comes into play - but I only have a basic understanding of JS package loading mechanisms like hoisting, etc.

@ajroach
Copy link

ajroach commented Sep 20, 2023

Any luck here? I'm seeing a similar issue, and adding resolve.dedupe didn't change anything for me either.

@ArloL
Copy link
Author

ArloL commented Oct 15, 2023

I got a little further: the second react comes from the root library. Apparently it starts searching the directory tree upward from where the actual JS file is (test-projects/workaround-package/dist/index.js) - not where it "is" via the symlink (test-projects/vite-project/node_modules/vitest-link-reproduction/dist/index.js). That search never comes across the react we want (test-projects/vite-project/node_modules/react) and then it finds what it needs in the root (node_modules/react). And that is how it ends up being there twice. Now how to solve that … no idea … something like --preserve-symlinks sounds like it does what I want, or am I missing something?

@sheremet-va
Copy link
Member

something like --preserve-symlinks sounds like it does what I want, or am I missing something?

There is resolve.preserveSymlinks option: https://vitejs.dev/config/shared-options.html#resolve-preservesymlinks

@ArloL
Copy link
Author

ArloL commented Oct 15, 2023

Thanks for the quick suggestion ☺️. I think I tried it before and it did not work. To be safe I just added it to my reproduction: ArloL/vitest-link-reproduction@8e3f122

Sadly the link build still fails: https://github.com/ArloL/vitest-link-reproduction/actions/runs/6526130338/job/17719549269

I just saw that the log actually confirms my suspicion that the root react is used:

at Object.useRef (/…/vitest-link-reproduction/node_modules/react/cjs/react.development.js:1630:21)
at Button (/…/vitest-link-reproduction/node_modules/@mui/base/node/Button/Button.js:54:27)

@cpakken
Copy link

cpakken commented Nov 8, 2023

Maybe this will help, I'm working with a linked custom package that reuses the same dependency and solved it with resolve.mainFields and forcing to use use esmodules first. This seems to fix it for me

  resolve: {
    dedupe: ['mobx'], //mobx is in custom linked package and main package
    mainFields: ['module', 'main'], //this is needed to work
  },

@ArloL
Copy link
Author

ArloL commented Nov 8, 2023

@hi-ogawa
Copy link
Contributor

It looks like adding @mui/base to resolve.dedupe and removing preserveSymlinks fixes it.

https://stackblitz.com/edit/github-uvwz3x?file=test-projects%2Fvite-project%2Fvite.config.js

Currently @mui/base is coming from (root)/node_modules/@mui/base and thus it ends up pulling react from (root)/node_modules/react while test-projects/vite-project/src/Test.test.jsx is using react from (root)/test-projects/vite-project/node_modules/react. After deduping, @mui/base will come from (root)/test-projects/vite-project/node_modules/@mui/base and thus it can see the same react as vite-project tests.

While debugging and studying the internal of Vite resolve.dedupe, I found that DEBUG=vite:resolve-details might come in handy to see where @mui/base is coming from during Vitest.

Running DEBUG=vite:resolve-details yarn run test
❯ DEBUG=vite:resolve-details yarn run test
yarn run v1.22.19
$ vitest
  vite:resolve-details [package entry] vite -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/vite/dist/node/index.js +0ms
  vite:resolve-details [package entry] @vitejs/plugin-react -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/@vitejs/plugin-react/dist/index.mjs +14ms
  vite:resolve-details [package entry] vitest -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/vitest/dist/index.js +166ms

 DEV  v1.1.0 /home/projects/github-uvwz3x/test-projects/vite-project

  vite:resolve-details [@fs] /@fs/home/projects/github-uvwz3x/test-projects/vite-project/node_modules/vite/dist/client/env.mjs -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/vite/dist/client/env.mjs +2s
  vite:resolve-details [@fs] /@fs/home/projects/github-uvwz3x/test-projects/vite-project/node_modules/vite/dist/client/env.mjs -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/vite/dist/client/env.mjs +1ms
  vite:resolve-details [fs] /home/projects/github-uvwz3x/test-projects/vite-project/src/Test.test.jsx -> /home/projects/github-uvwz3x/test-projects/vite-project/src/Test.test.jsx +709ms
  vite:resolve-details [fs] /home/projects/github-uvwz3x/test-projects/vite-project/src/Test.test.jsx -> /home/projects/github-uvwz3x/test-projects/vite-project/src/Test.test.jsx +0ms
  vite:resolve-details [package entry] @testing-library/react -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/@testing-library/react/dist/index.js +21ms
  vite:resolve-details [package entry] vitest-link-reproduction -> /home/projects/github-uvwz3x/test-projects/workaround-package/dist/vitest-link-reproduction.js +1ms
  vite:resolve-details [node/deep-import] ./jsx-dev-runtime -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/react/jsx-dev-runtime.js +1ms
  vite:resolve-details [package entry] vitest -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/vitest/dist/index.js +0ms
  vite:resolve-details [fs] /home/projects/github-uvwz3x/test-projects/workaround-package/dist/vitest-link-reproduction.js -> /home/projects/github-uvwz3x/test-projects/workaround-package/dist/vitest-link-reproduction.js +158ms
  vite:resolve-details [fs] /home/projects/github-uvwz3x/test-projects/workaround-package/dist/vitest-link-reproduction.js -> /home/projects/github-uvwz3x/test-projects/workaround-package/dist/vitest-link-reproduction.js +0ms
  vite:resolve-details [package entry] @mui/base -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/@mui/base/node/index.js +2ms
  vite:resolve-details [package entry] react -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/react/index.js +0ms

 ✓ src/Test.test.jsx (1)
   ✓ renders a button

 Test Files  1 passed (1)
      Tests  1 passed (1)
   Start at  17:22:09
   Duration  2.54s (transform 

@ArloL
Copy link
Author

ArloL commented Dec 28, 2023

Thanks, @hi-ogawa. What you describe makes perfect sense and I can confirm that it fixes my issue.

I am not sure if my assumptions are reasonable but I would expect that preserveSymlinks works just the same.

@hi-ogawa
Copy link
Contributor

hi-ogawa commented Dec 28, 2023

I am not sure if my assumptions are reasonable but I would expect that preserveSymlinks works just the same.

Good point. I'm testing with preserveSymlinks further and I think what's happening is that, with this option, vitest-link-production is resolved as node_modules/vitest-link-reproduction/dist/vitest-link-reproduction.js, but then Vitest's node_modules externalization kicks in, so Vitest/Node runtime will eventually import this vitest-link-reproduction.js, which then maybe ends up following symlink again.
(This is my quick guess after fiddling with options, so I could be wrong though...)

To prevent "externalizing" it, I think there is test.server.deps.linline otpion, so doing this seems to work:

https://stackblitz.com/edit/github-uvwz3x-6kmuvy?file=test-projects%2Fvite-project%2Fvite.config.js

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  resolve: {
    dedupe: ['react', 'react-dom', 'react/jsx-runtime'],
    preserveSymlinks: true,
  },
  test: {
    environment: 'jsdom',
    server: {
      deps: {
        inline: [/vitest-link-reproduction/],
      },
    },
  },
});

And this what I see when running DEBUG=vite:resolve-details yarn run test run:

  vite:resolve-details [url] /node_modules/vitest-link-reproduction/dist/vitest-link-reproduction.js -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/vitest-link-reproduction/dist/vitest-link-reproduction.js +164ms
  vite:resolve-details [url] /node_modules/vitest-link-reproduction/dist/vitest-link-reproduction.js -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/vitest-link-reproduction/dist/vitest-link-reproduction.js +1ms
  vite:resolve-details [package entry] @mui/base -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/@mui/base/node/index.js +1ms
  vite:resolve-details [package entry] react -> /home/projects/github-uvwz3x/test-projects/vite-project/node_modules/react/index.js +1ms

@ArloL
Copy link
Author

ArloL commented Dec 29, 2023

Sadly that setup fails for me: ArloL/vitest-link-reproduction#80

@sheremet-va sheremet-va added p2-edge-case Bug, but has workaround or limited in scope (priority) and removed bug labels Feb 16, 2024
martypdx added a commit to azothjs/azoth that referenced this issue Mar 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p2-edge-case Bug, but has workaround or limited in scope (priority)
Projects
None yet
Development

No branches or pull requests

6 participants