Skip to content
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

[Bug]: ng test does not work for o3r-generated library in pnp #2620

Open
cpaulve-1A opened this issue Dec 18, 2024 · 1 comment
Open

[Bug]: ng test does not work for o3r-generated library in pnp #2620

cpaulve-1A opened this issue Dec 18, 2024 · 1 comment
Labels
bug Something isn't working priority:high

Comments

@cpaulve-1A
Copy link
Contributor

Package name

workspace

Package version

11.5.0

Reproduction steps

Generate an o3r project with yarn as packageManager and generate a library.
Run yarn ng test my-lib. Test should work.
Update the yarnrc to set nodeLinker: pnp and run the yarn install.
Now, run the test command.

Current result

Test fails with error:
Error: error TS2688: Cannot find type definition file for 'jasmine'. The file is in the program because: Entry point of type library 'jasmine' specified in compilerOptions
and errors such as Cannot find name 'beforeEach'.

Expected result

Test should not fail

Additional comments

Issue seems to come from the fact that jasmine is not part of the devDependencies of the library project and is only available in the root package and that the project is in pnp with defined workspace.
Yarn pnp expects that each module works in isolation and the generated library misses the @types/jasmine devDependency.
(See yarnpkg/berry#1058 (comment))

We need to keep in mind that we cannot just add this devDependency as it was brought by angular create and library generator. It is not recommended to add dependencies that we do not bring ourselves.

In this issue, we need to consider whether we keep the support of pnp for our generated module, if we remove the workspace property from the generated root package.json (and see the impact on project size et dev experience) or if we can find an alternative solution.

@kpanot
Copy link
Contributor

kpanot commented Dec 19, 2024

Hi,

I don't think that removing the workspace property is a solution, it will lead to many other issues.

I would have a question: do we want to keep the Jasmine brought by Angular when we (including company guidelines) recommend to use Jest?
We can maybe remove it in install process to replace it to Jest.

A simple workaround (to keep temporary Jasmine) is to simply copy past the Jasmine devDependency from the workspace package.json into the new library devDependency.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority:high
Projects
None yet
Development

No branches or pull requests

2 participants