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] workspaces packages are built in parallel after npm ci even though they depend on each other #4475

Closed
2 tasks done
dreamorosi opened this issue Feb 26, 2022 · 3 comments
Labels
Enhancement new feature or improvement Priority 2 secondary priority issue Release 8.x work is associated with a specific npm 8 release

Comments

@dreamorosi
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

This issue exists in the latest npm version

  • I am using the latest npm

Current Behavior

I'm using [email protected] and making use of the workspaces feature, my (simplified) project's structure is the following:

my_project
|_ packages
   |_ commons
   |_ logger
   |_ metrics
   |_ tracing
package.json 

In my package.json file I have the following config:

"workspaces": [
    "packages/*"
 ]

The project uses TypeScript and the packages logger, metrics, tracing all depend on commons.

When I run npm ci in my CI/CD environment (GitHub Actions) after installing the dependencies npm tries to build (tsc) the packages but appear to do so in parallel and so the build of all the dependant packages fails because it's being done before commons is ready.

Expected Behavior

Npm to understand that some packages of the workspace are dependant on others and build accordingly.

Alternatively to allow me to specify that I want to use a remote (i.e. not linked) version of the package even though the version number is the same as the local one.

Steps To Reproduce

Read above, also you can see the error (with logLevel == silly) here https://github.com/dreamorosi/aws-lambda-powertools-typescript/runs/5345787297?check_suite_focus=true#step:6:5380 (<- Line that causes the error)

Environment

  • npm: 8.5.2
  • Node.js: lts/fermium (aka 14.x)
  • OS Name: Ubuntu
  • System Model Name: GitHub Actions
  • npm config: N/A
@dreamorosi dreamorosi added Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release labels Feb 26, 2022
@dreamorosi dreamorosi changed the title [BUG] <title> [BUG] workspaces packages are built in parallel after npm ci even though they depend on each other Feb 26, 2022
@lukekarrys
Copy link
Contributor

What package.json script are you using to run tsc? If it's prepare then a workaround is to use the --foreground-scripts flag (or set it in your project .npmrc) and manually order the your "workspaces": [] array to be the order you want them to be run.

There's more info in #3034 and #4100. This might be a duplicate of one of those, but I will live this open in case it's something else.

@lukekarrys lukekarrys added Enhancement new feature or improvement Priority 2 secondary priority issue and removed Needs Triage needs review for next steps Bug thing that needs fixing labels Feb 27, 2022
@dreamorosi
Copy link
Author

Hello @lukekarrys, thanks for the quick reply, really appreciate it. I wasn't aware that the issue was in the prepare script and so I was searching for install or ci and didn't find the other two issues.

We are indeed using prepare in our project. I had already tried to explicitly order the "workspaces": [] but without --foreground-scripts it still failed.

I can confirm that using the combination of both that you suggested works.

The two action items you mentioned in this comment are a must in my opinion. Documentation could clarify this behaviour but also a specific flag to control this behaviour would be useful as the link between --foreground-scripts and concurrency/parallel execution is not immediately clear, at least for those not familiar with the inner workings of the project.

If you prefer to close this issue as duplicate of #4100 feel free to, I'll subscribe to that one in that case.

@lukekarrys
Copy link
Contributor

Thanks for the follow-up @dreamorosi, and I'm glad that workaround was able to resolve your initial problem. I'm going to close this and we can track it the other linked issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement new feature or improvement Priority 2 secondary priority issue Release 8.x work is associated with a specific npm 8 release
Projects
None yet
Development

No branches or pull requests

2 participants