Secondary entry-point package.json files in APF require mainFields resolution (in Vitest)

[Jordan-Hall]

Which @angular/* package(s) are the source of the bug?

core, router, Don't known / other

Is this a regression?

No - but not sure

Description

I'm trying to get unit test working with vite test. I've ran into an issue when importing testing modules

Error: Failed to resolve entry for package "@angular/core/testing". The package may have incorrect main/module/exports specified in its package.json: Failed to resolve entry for package "@angular/core/testing". The package may have incorrect main/module/exports specified in its package.json.

This also applies to the router module.

Please provide a link to a minimal reproduction of the bug

https://github.com/Jordan-Hall/vite-angular-template

Please provide the exception or error you saw

No response

Please provide the environment you discovered this bug in (run ng version)

_                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 13.1.4
Node: 16.13.0
Package Manager: npm 8.4.0
OS: win32 x64

Angular: 13.1.3
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1301.4
@angular-devkit/build-angular   13.1.4
@angular-devkit/core            13.1.4
@angular-devkit/schematics      13.1.4
@angular/cli                    13.1.4
@schematics/angular             13.1.4
rxjs                            7.4.0
typescript                      4.3.5

Anything else?

This projects uses NX and prototype of an angular cite plugin.

[devversion]

Thanks for this issue @Jordan-Hall. I would be happy to look into this. Looking at the current exports being generated in our package.json, I can see ./testing being declared properly with the expected conditions.

https://github.com/angular/core-builds/blob/master/package.json#L25

In your repository, what would be the steps to reproduce the issue? I assume just test, but it's always good to be explicit when a reproduction is provided (saving some time)

[devversion]

The reproduction does fail in the npm install since your lock file seems to rely on a local registry (using e.g. verdaccio).

[Jordan-Hall]

Hey @devversion https://github.com/Jordan-Hall/vite-angular-template this should be a better test repo. Sorry it's taken so long wanted next beta release off the compiler to be release.

[sheremet-va]

Not sure if these conditions are valid Native Node conditions? Maybe you should have “import” as a fallback as the last condition? Although it has default condition, which I guess should be a fallback 🤔

[devversion]

Thanks for the update @Jordan-Hall. @sheremet-va: Yes, some conditions are custom to allow the Angular CLI/or users to have more control over which output flavor they prefer. Custom conditions are totally valid.

As you said, the default condition should match here ("import") should not be needed). After some investigation I figured out why this error surfaces:

1. Angular libraries (including the official packages) expose secondary package.json files for TypeScript resolution. e.g. node_modules/@angular/core/testing/package.json. This will be the package.json picked up for the resolution.
2. These secondary package.json files do not have exports defined since these are not at the package top-level.
3. Vitest seems to have the mainFields for non-exports resolution set to an empty array (only looking for main since this loop will never run)
4. Adding an explicit mainFields resolution setting, fixes the issue.

e.g.

export default defineConfig({
  resolve: {
    mainFields: ['fesm2020', 'fesm2015', 'module'],
  }
});

[devversion]

FWIW: I want to remove these secondary package.json files (Angular Package Format v13 was a step towards this), but currently this is not a planned task. I might get to it indirectly when refactoring some things for better d.ts bundling.

[devversion]

Closing as this is not an issue with Angular. I provided a workaround, and the issue is now mitigated with the upcoming v14

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}