ojkelly/yarn.build

Dependency tracking and Docker build cache

Closed this issue · 3 comments

jscheid commented

Describe the bug

At least when using Yarn 2.x and workspaces (but possibly also when using Yarn 1.x?) the dependency resolution doesn't seem to be precise enough, preventing full use of the Docker build cache.

To Reproduce

See https://github.com/jscheid/yarn-build-docker-test

Expected behavior

It shouldn't try to build packageB or packageC in line 23 of the Dockerfile since packageA doesn't depend on these packages.

Screenshots
N/A

Desktop (please complete the following information):
N/A

Additional context
N/A

ojkelly commented

ooh this is an interesting bug. Thanks for putting together the repro repo. I'll try and dig into that in the next few days.

I would note the repro seems a bit too small, in that the build step doesn't produce any actual outputs, which breaks an assumption of the build cache tracker.

Still, something to dive into.

jscheid commented

Hey, thanks for taking a look. If you run the repro you'll see that it never gets to the point where it would produce output, so it shouldn't matter.

  • 👍1
ojkelly commented

Argh I completely missed the error the first time I looked at this. Sorry this is likely an issue with documentation that's resolved as the feature is available without a flag in the latest version.

The version you had installed didn't support passing the package to build to yarn build. Calling yarn build from the anywhere in the repo that is not a package will build all packages.

Updating the Dockerfile with the following resolves the issue:

ADD packages/packageA/ ./packages/packageA/
RUN cd packages/packageA && yarn build && cd ../..

# Copy and build packageB
ADD packages/packageB/ ./packages/packageB/
RUN cd packages/packageB &&yarn build && cd ../..

# Copy and build packageC
ADD packages/packageC/ ./packages/packageC/
RUN cd packages/packageC &&yarn build && cd ../..

The latest version of yarn.build (supporting yarn v3) allows you to run yarn build packages/packageC.

In the previous version there was a flag, but if that was turned on it still wouldn't work as we need the full path packages/packageC not just the package name packageC as it is in the repro.