Vite >=3.1.5 breaks Jotai babel plugins

[gunters63]

Describe the bug

Vite 3.1.5 changed the processing of package exports. This breaks two Jotai plugins (debug-label and react-refresh).

vite dev chokes with the following error:

Reverting to 3.1.4 makes the error go away.

The author of Jotai thinks this may be a vite problem, not a problem with Jotai itself.

See discussion with initial analysis here: pmndrs/jotai#1475

Reproduction

https://github.com/gunters63/jotei-vite-import-error

Steps to reproduce

pnpm install, then pnpm dev

System Info

System:
    OS: Windows 10 10.0.22621
    CPU: (16) x64 AMD Ryzen 9 6900HS with Radeon Graphics        
    Memory: 6.27 GB / 31.26 GB
  Binaries:
    Node: 18.10.0 - C:\Program Files\nodejs\node.EXE
    npm: 8.19.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22621.608.0), Chromium (106.0.1370.37)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    vite: 3.1.7 => 3.1.4

Used Package Manager

pnpm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[frsimond]

About this, isn't there a problem with the versioning on npm ?
The CHANGELOG.md mentions last stable to be 3.1.3. But on npm there are 3.1.4 to 3.1.7

[aleclarson]

It appears this is still an issue, as #10528 and #10683 only affect config bundling.

/cc @sapphi-red

[aleclarson]

I think the plan is to allow users to omit "module" from the resolve.conditions option in order to prevent it from being used (assuming I fully understand the intent of #10683).

In my opinion, Vite shouldn't use the module condition by default, and users can add it to resolve.conditions if they depend on a misconfigured package.

/cc @Dunqing @benmccann (since you two had opinions in #10442)

[Dunqing]

I think the plan is to allow users to omit "module" from the resolve.conditions option in order to prevent it from being used (assuming I fully understand the intent of #10683).

In my opinion, Vite shouldn't use the module condition by default, and users can add it to resolve.conditions if they depend on a misconfigured package.

I agree with you.

[bluwy]

@aleclarson Isn't this issue about config bundling only? module being used in the normal Vite pipeline isn't part of this issue.

I think the plan is to allow users to omit "module" from the resolve.conditions option in order to prevent it from being used (assuming I fully understand the intent of #10683).

I don't think that's the intent of the PR. It's fixing an issue with config bundling only.

[sapphi-red]

I think the plan is to allow users to omit "module" from the resolve.conditions option in order to prevent it from being used (assuming I fully understand the intent of #10683).

I implemented in a way that we could do like that in future. But that is not the main intent of that PR. The intent was to make module not be used when config bundling.

I think removing module condition from the normal Vite pipeline is a different thing from this issue. (IMO Vite should use module condition for isRequire: false because of the intent of this condition: webpack/webpack#11014, rollup/rollup#3514, https://github.com/rollup/plugins/tree/master/packages/node-resolve#exportconditions)

About chaging the resolve.conditions, I've left explanations about it in #10917.

[aleclarson]

Isn't this issue about config bundling only?

Ah ok, my mistake!

I think the plan is to allow users to omit "module" from the resolve.conditions option in order to prevent it from being used (assuming I fully understand the intent of #10683).

I implemented in a way that we could do like that in future. But that is not the main intent of that PR. The intent was to make module not be used when config bundling.

Yeah, I worded my comment poorly. I wasn't saying that it was the only or even the main intent of #10683, but I noticed it was implied in the overrideConditions description.