Rule node have been renamed to Declarations

I would highly recommend anyone having speed issues to profile jest and look at what's taking the time.

In my experience most of the time taken in jest is re-importing files separately per test suite. e.g. we had some global afterEach to reset state, but it meant the files were imported every test when they weren't needed. Same issue for the setup of enzyme of react testing library. Some refactoring to improve global test imports can make a massive difference.

How does vitest "solve" this problem? You either re-import every test suite and have separation or you don't and import mocking / reset of state doesn't work (or I guess you have some clever dependency tracking to only re-import what you need for import mocking to work).

Hi,

any plan to fix this @kinyoklion ?

I saw this appear in the typescript 5.3 iteration plan..

Since no-one has mentioned it, I use a extension that does this already: "Copy With Imports" - id: stringham.copy-with-imports

Its a awesome time saver. I particularly like that copy pasting a exported symbol will add a import to that export.

Self-service

• [ ] I'd be willing to implement a fix

Describe the bug

running

yarn dlx -q envinfo --preset jest

gives the output:

Internal Error: ENOENT: no such file or directory, open 'C:\Users\xxx\AppData\Local\Temp\xfs-b6733aeb\dlx-14808\.env'
Error: ENOENT: no such file or directory, open 'C:\Users\xxx\AppData\Local\Temp\xfs-b6733aeb\dlx-14808\.env'

with the config

compressionLevel: mixed

enableGlobalCache: true

enableStrictSsl: false

httpTimeout: 1000000

injectEnvironmentFiles:
  - .env
  - .env.user?

nodeLinker: node-modules

I can add a ? after .env to make it optional but then all users would have to always make the env files optional for them to work with yarn dlx, so it seems like bug.

To reproduce

See above

Environment

System:
    OS: Windows 10 10.0.19045
    CPU: (12) x64 Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
  Binaries:
    Node: 18.16.1 - ~\AppData\Local\Temp\xfs-968f78b9\node.CMD
    Yarn: 4.0.0-rc.48.git.20230729.hash-8d70543 - ~\AppData\Local\Temp\xfs-968f78b9\yarn.CMD
    npm: 9.5.1 - C:\Program Files\nodejs\npm.CMD
  npmPackages:
    jest: 29.4.2 => 29.4.2

Additional context

No response

We got the same issue, so adding some info here in case it helps.

Firstly I'm not sure why the reccomended approach is to import * as since dompurify has a single default export: https://github.com/cure53/DOMPurify/blob/main/dist/purify.es.js#L1662 We import the default import.

When dompurify recently introduced more modern javascript into its default dist/purify.js bundle, babel kicked in and because we use @babel/transform-runtime, it added imports to the purify.js file so that webpack recognised it as a ecmascript module even though it is not - the end result seems to be nothing is exported and the import is undefined.

The fix for us was to tell webpack to resolve to the dist/purify.es.js file and then it worked.

No worries - I found upgrading from yarn v1 fixed it for me.

Perfect, thanks - that works.

I just discovered it also errors when I run the command to setup my editor

yarn dlx @yarnpkg/sdks vscode

Internal Error: ENOENT: no such file or directory, open 'C:\Users\xxxx\AppData\Local\Temp\xfs-e4f23b26\dlx-12060\.env'
Error: ENOENT: no such file or directory, open 'C:\Users\xxxx\AppData\Local\Temp\xfs-e4f23b26\dlx-12060\.env'

which must be a bug?

this package has minimatch as "*", but the latest version of minimatch removes the default export.

Searching for the error I see a few stack overflow posts about puzzled people who cannot work out what is happening - the stack trace doesn't show who is using "run". I don't know if its a old version of npm/npx etc ?

but somehow run is getting ran and its minimatch dependency has picked up the latest v9, then it fails.

I was trying it out, thanks. Its worth noting that if you specify a env file that does not exist, you get an error, which means the use-case of .env.user that is git ignored is bad dx (the user needs to create an empty env file in order to run yarn install)

ok sorry,

When I have a failing prettier file, if I leave off --check I get the above exception.

But when I add the check param then it says there are no issues, even though there are.

probably because isFormatted returned from prettier.check is now a promise

I get this issue (note - I do not use flow)

Confirmed - same for me.

I got warnings about unknown config options and at first I thought this was the issue, but it was because the plugin was no longer auto loaded.