How can I get my GH Action tests to use the NPM version of a peer package?

I have a yarn monorepo, and am making a change to one of the packages that other packages rely on.

I increment my package version on publication, so although my PR includes breaking changes, I have not adjusted the package.json version. Unfortunately i seems that something in my GH actions (maybe something in actions/checkout@v2?) seems to have some logic that involves not checking out if the dependency matches the local version.

Is there any way to have it pull from NPM instead?

Here’s the action: appliances/test.yml at aeb1455f166a7a5ad21e886ed69c494972f8372a · tvkitchen/appliances · GitHub

I don’t think that’s correct, certainly, I have not observed that before: I think this is an issue specific to the monorepo set-up you have. The monorepo tooling is responsible for creating the appropriate dependency linkage through node_modulesactions/checkout just pulls down your repository contents.

As I understand it, the expectation of a monorepo is that the packages are all compatible with each commit, that is, if you introduce a breaking change to Package A then you must update Package B at the same time to be compatible. A monorepo (in the node world at least) is not multiple independent packages in one repository, it’s multiple dependent packages in one repository.

A good first step to debugging this would be to upload an artifact containing the whole Action workspace, from there you can step through each dependency and identify any issues, e.g:

- name: Upload runner Workspace as artifact
  if: always()
  uses: actions/upload-artifact@v2
  with:
      path: "."
      name: "workspace"
1 Like

Much appreciated and you are certainly right – (as you were responding I actually modified that section to be less conclusion-jumping). I don’t know why this didn’t manifest when I was using other CI solutions, but I think it was just luck.

I also appreciate your point about the monorepo expectations! Given that, I’ll take this situation as actually a legitimately failing test and go fix my code.

I could be wrong: during my own monorepo set-up process, I struggled to find any authoritative description of exactly how I should expect some of the finer points to be addressed. I know that Yarn (and npm, and Lerna) do – as you describe in your opening post – pull from npm when they cannot resolve a version locally so if you do want to have backwards incompatibility within the monorepo, it is possible:

  1. Make a backwards-incompatible change in package-a
  2. Update package-a/package.json's version to 2.0.0-alpha.1 (where 2 is the next major version)
  3. Run yarn install and observe that any package in the monorepo depending on version 1.x.x of package-a will pull package-a from the registry instead of using the local copy
1 Like