The package may have incorrect main/module/exports specified in its package.json

[nemonemi]

Describe the bug

I am importing our custom UI library, which is an NPM package that has the following defined in its package.json.

    "main": "dist/index.js",
    "module": "dist/index.modern.js",

When I run the build I get an error pointing me toward this package.json

>  NX   Failed to resolve entry for package "@our-custom/ui-components". The package may have incorrect main/module/exports specified in its package.json.

When I adjust the module to point to the index.js everything works fine and as expected

    "main": "dist/index.js",
    "module": "dist/index.js",

The difference between the index.js and index.modern.js is that the index.modern.js is not transpiled, so it has imports, consts etc.

Reproduction

Cannot provide it at the moment

Steps to reproduce

No response

System Info

System:
    OS: Linux 5.15 Ubuntu 20.04.5 LTS (Focal Fossa)
    CPU: (8) x64 Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz
    Memory: 17.47 GB / 31.00 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 16.14.0 - ~/.volta/tools/image/node/16.14.0/bin/node
    Yarn: 3.4.1 - ~/.volta/tools/image/yarn/1.22.19/bin/yarn
    npm: 8.3.1 - ~/.volta/tools/image/node/16.14.0/bin/npm
  Browsers:
    Chrome: 110.0.5481.177
    Firefox: 110.0.1
  npmPackages:
    @vitejs/plugin-react: ^3.0.0 => 3.1.0 
    vite: ^4.0.1 => 4.1.4 

### Used Package Manager

yarn

### Logs

_No response_

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitejs/vite/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitejs/vite/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitejs.dev/guide).
- [X] Check that there isn't [already an issue](https://github.com/vitejs/vite/issues) that reports the same bug to avoid creating a duplicate.
- [X] 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](https://github.com/vuejs/core) instead.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitejs/vite/discussions) or join our [Discord Chat Server](https://chat.vitejs.dev/).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

[github-actions]

Hello @nemonemi. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with need reproduction will be closed if they have no activity within 3 days.

[fi3ework]

A minimal reproduction is needed to address this issue.

[nemonemi]

@fi3ework it is tricky to simulate it because it depends on several systems.
I would have to create an NPM package that exports 2 versions, an ES5 and ES6+, and then have it imported as a dependency, and then perform a build on the application that consumes it.

This would take quite a while to set up, and I don't think 3 days is enough for me to set this up, taking my other daily tasks into consideration.

Before adding Vite, I've been using only Webpack, and everything worked as expected.
Now, I've created several libraries in NX that are handled by Vite, but the main application still has Webpack.

The point that I'm getting at here is that there's a difference in parsing on the Vite side of this type of code:
Legacy

'use strict';

var React$1 = require('react');
var reactUse = require('react-use');
var utils = require('@mui/material/utils');
var O = require('optics-ts');
var deepEqual = require('fast-deep-equal/es6');
var SearchIcon = require('@mui/icons-material/ManageSearchRounded');
var MuiButton = require('@mui/material/Button');
var ArrowDropDownIcon = require('@mui/icons-material/ArrowDropDownRounded');
var DropUpIcon = require('@mui/icons-material/ArrowDropUpRounded');
var ClickAwayListener = require('@mui/material/ClickAwayListener');

compared to this type of code:
Modern

import * as React$1 from 'react';
import React__default, { useContext, useMemo, useState, useCallback, useRef, useLayoutEffect, useEffect, forwardRef, createRef, createContext } from 'react';
import { useGetSet } from 'react-use';
import { debounce } from '@mui/material/utils';
import * as O from 'optics-ts';
import deepEqual from 'fast-deep-equal/es6';
import SearchIcon from '@mui/icons-material/ManageSearchRounded';
import MuiButton, { buttonClasses } from '@mui/material/Button';
import ArrowDropDownIcon from '@mui/icons-material/ArrowDropDownRounded';
import DropUpIcon from '@mui/icons-material/ArrowDropUpRounded';
import ClickAwayListener from '@mui/material/ClickAwayListener';

Is there a way to configure Vite to take either the Legacy or Modern, or to inform it to parse the Modern one?

[fi3ework]

I'm afraid not, Vite's fundamental idea is based on native ESM (modern), although there's @vitejs/plugin-legacy, it only works on production mode.

[bigtallbill]

I've experienced a similar issue recently at work. (forgive me as i'm mostly backend these days)

We have an internal UI library that we import to various react projects which use webpack. I started a new project in wails.io which uses vite. We were getting this exact error for our UI library The package may have incorrect main/module/exports specified in its package.json when doing simple imports import { BTN } from '@company/uilib'

We also had both a main & module entry in the package.json. From what we could tell, vite was preferring the module entry, whereas the projects running webpack seemed to prefer main. Our solution was just to remove module from the ui lib's package.json, this seemed to satisfy all our build systems.

Additionally, our UI library is targeting umd.

[nemonemi]

@fi3ework my preferred solution would be for Vite to recognize the ESM (modern) version that it is accessing from the module property in package.json, which it, currently does not.

Removing the module property or setting it to return the legacy code, although it would suffice, is not really the point here or possible in some cases.
It is there so that the tools that expect it, as @fi3ework suggests, could use it.

[fi3ework]

Vite recognizes module field (link) and also could handle ESM imports and ES5 syntax. So a reproduction is needed to address the specific issue.