Skip to content

fix(@angular/build): allow TestBed provider configuration with vitest unit-testing #30276

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

clydin
Copy link
Member

@clydin clydin commented May 8, 2025

The experimental unit-test builder with the vitest runner configured can now specify an Angular providers file via the providersFile option. This allows the TestBed initialization to use the providers defined in this file for all executed tests. The contents of the providers file should include a default export with an array of one or more Angular providers. As an example:

import { provideZonelessChangeDetection } from '@angular/core';

export default [
  provideZonelessChangeDetection(),
];

… unit-testing

The experimental `unit-test` builder with the `vitest` runner configured
can now specify an Angular providers file via the `providersFile` option.
This allows the TestBed initialization to use the providers defined in
this file for all executed tests. The contents of the providers file should
include a default export with an array of one or more Angular providers.
As an example:
```
import { provideZonelessChangeDetection } from '@angular/core';

export default [
  provideZonelessChangeDetection(),
];

```
@clydin clydin added the target: rc This PR is targeted for the next release-candidate label May 8, 2025
@clydin clydin requested a review from alan-agius4 May 8, 2025 23:48
@clydin clydin marked this pull request as ready for review May 8, 2025 23:48
Copy link
Contributor

@jkrems jkrems left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a really neat solution for this!

@alan-agius4 alan-agius4 added the action: review The PR is still awaiting reviews from at least one requested reviewer label May 9, 2025
Copy link
Collaborator

@alan-agius4 alan-agius4 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See feedback

`import { getTestBed, ɵgetCleanupHook as getCleanupHook } from '@angular/core/testing';`,
`import { BrowserTestingModule, platformBrowserTesting } from '@angular/platform-browser/testing';`,
`import { beforeEach, afterEach } from 'vitest';`,
'',
normalizedOptions.providersFile
? `import providers from './${path.relative(projectSourceRoot, normalizedOptions.providersFile)}'`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of notes:

  1. path.relative will return backslashes on Windows, which will break the import paths.
  2. The file extension (.ts) is retained. Can this cause issues? (I guess not as this is not typechecked).
  3. Instead of using projectSourceRoot, it probably makes more sense to use workspaceRoot, since paths in angular.json are all relative to the workspace root.

We handle a similar case here for reference:

function entryFileToWorkspaceRelative(workspaceRoot: string, entryFile: string): string {
return (
'./' +
relative(workspaceRoot, entryFile)
.replace(/.[mc]?ts$/, '')
.replace(/\\/g, '/')
);
}

"providersFile": {
"type": "string",
"description": "TypeScript file that exports an array of Angular providers to use during test execution. The array must be a default export.",
"minLength": 1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is "minLength": 1 intentional?

@alan-agius4 alan-agius4 added action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels May 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews area: @angular/build target: rc This PR is targeted for the next release-candidate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants