fix(config): don't resolve by exports.module field

[Dunqing]

Description

fix: #10430
related: #10347

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[benmccann]

If this were going to be changed, you would need to update the docs: https://vitejs.dev/config/shared-options.html#resolve-conditions

It looks like this was originally added to support tslib: 3a3029e. That change didn't have a test and I'm not that familiar with why it was added, so I'd want to make sure that removing it isn't breaking anything

I don't understand the motivation for this change or why jotai is setup the way it is. I've asked some questions to clarify in that issue: pmndrs/jotai#1475 (comment)

[Dunqing]

If this were going to be changed, you would need to update the docs: https://vitejs.dev/config/shared-options.html#resolve-conditions

Thank you, updated.

It looks like this was originally added to support tslib: 3a3029e. That change didn't have a test and I'm not that familiar with why it was added, so I'd want to make sure that removing it isn't breaking anything

Yeah, It seems to me that there is no need to support exports.module.

[benmccann]

Yeah, It seems to me that there is no need to support exports.module.

I'm not sure how you came to that conclusion. I see tslib still has an exports.module field:

I think probably no project should be using exports.module as it's a completely non-standard thing. However, it seems to me that if we were to remove it we'd likely break a lot of existing projects since tslib is so widely used. If you want to remove it here, you should fix tslib first: microsoft/tslib#183

I think it should also be removed from jotai. If I have to choose between jotai being broken or tslib being broken, I prefer that jotai is the one that's broken since it has fewer users.

[Dunqing]

I'm not sure how you came to that conclusion. I see tslib still has an exports.module field:

Yes, as you can see, tslib also still has exports.import, which is enough for vite to successfully resolve

I think probably no project should be using exports.module as it's a completely non-standard thing. However, it seems to me that if we were to remove it we'd likely break a lot of existing projects since tslib is so widely used. If you want to remove it here, you should fix tslib first: microsoft/tslib#183

I think it should also be removed from jotai. If I have to choose between jotai being broken or tslib being broken, I prefer that jotai is the one that's broken since it has fewer users.

I don't think we need to do anything except remove support for resolve.module. Because we still support the standard exports.

[sapphi-red]

superseded by #10528