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

[nemonemi]

Current Behavior

I have a library, which can no longer be generated with Webpack, that consumes a custom npm package, and when building it, it fails with the following message

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

I have also reported it to Vite, but haven't had a chance, as of yet, to create a reproducible example.

At the moment, the library's package.json defines both main and module properties

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

where the first one's content looks as if it was transpiled for ie5

'use strict';

var React$1 = require('react');
var reactUse = require('react-use');
...

and the second one for the modern browsers

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';
...

Expected Behavior

It should work.

GitHub Repo

No response

Steps to Reproduce

Nx Report

Node   : 18.15.0
   OS     : linux-x64
   yarn   : 3.6.1
   
   nx                 : 16.5.3
   @nx/js             : 16.5.3
   @nx/jest           : 16.5.3
   @nx/linter         : 16.5.3
   @nx/workspace      : 16.5.3
   @nx/cypress        : 16.5.3
   @nx/eslint-plugin  : 16.5.3
   @nx/react          : 16.5.3
   @nx/webpack        : 16.5.3
   typescript         : 5.1.6

Failure Logs

No response

Package Manager Version

yarn

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

No response

[nemonemi]

Removing the "module" property resolves the issue, but I'm not sure if that's the desired approach, since one might not have the control over the library they consume.

[steven10172]

Related to #18492 (comment)

[teofilomonteiro]

@barbados-clemens left a comment that makes me very unhappy. This sounds like a breaking change release and not a feature release. It breaks the behaviour that it was before. Especially when migrating should keep everything working. Is there a workaround that doesn't involve changing the behaviour of the npm base repo?

[teofilomonteiro]

I will add more, the solution suggested just causes another issue. If you make changes to the lib, this will not trigger a reload of the app or a rebuild of the lib/app.

Just makes me wonder why do you support even the npm workspaces.

[joeldbirch]

I'm getting the same issue using yarn workspaces.

[teofilomonteiro]

I think another solution for this is to prevent the migration to use the `import { nxViteTsPaths } from '@nx/vite/plugins/nx-tsconfig-paths.plugin'; Something is missing on this plugin that makes it break.

If I still use vite-tsconfig-paths everything works as it should.

So the question now is, what does nxViteTsPaths try to solve?

[fsgreco]

Hello @teofilomonteiro I've just found a new solution for this, explained everything in detail here: #21030

TL;DR: you can change the paths alias inside the tsconfig.base.json, as long as it does not match the name of the custom package/library (its name inside its package.json it will work fine). I still repute it a bug but at least this is an easy and not invasive solution.

[teofilomonteiro]

@fsgreco I don't think we can use your solution because we are publishing packages. And from what I understood from your suggestion you need to rename the package. Is that correct?

[MBelniak]

Maybe this will help? #18931 (comment)

[fsgreco]

@teofilomonteiro actually you can change the strategy and rename the exports instead. The package will still have it's name, but you have to rename the pathname on the tsconfigfile*. As long as they don't match it should work 👍🏽

Ps: let me know how it goes, it's been a couple of months since I create this issue and found the solution.

* and with that also every import inside the app on the monorepo that consume them but that could be done with a general search and replace

[Coly010]

Closing as duplicate of #20520
Which also has a better reproduction.

Thanks everyone for chiming in here, this is all valuable information

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.