Repository navigation
presence of dynamic packages leads to linking error during leeway exec #100
Description
Bug description
leeway exec cannot find the dynamic package install/preview:docker (when it is building the dependency tree?) and fails with:
gitpod /workspace/gitpod/components/server (gpl/12758-list-plans) $ yarn watch
yarn run v1.22.19
$ leeway exec --package .:app --transitive-dependencies --filter-type yarn --components --parallel -- yarn build -w --preserveWatchOutput
FATA[0000] cannot load workspace error="linking error in package components:all: package \"install/preview:docker\" is unknown"
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.Steps to reproduce
- open https://gitpod.io/#https://github.com/gitpod-io/gitpod/commit/1516e4c4dfdfbf54660b60860d80fb37aa840a1c
cd components/serveryarn watch
Expected behavior
It should execute yarn builds instead
Example repository
No response
Anything else?
No response
Activity
csweichel commentedon Sep 29, 2022
This is actually caused by the "dynamic existence" of
installer/preview:docker. It only exists when the right arguments are passed at linking stage.Options:
Make
components:alldynamic.Doesn't require a leeway change, but significantly increases the complexity of our build set up because we have to duplicate conditions.
Add optional dependencies which are ignored if they're not present
For example (notice the ?) at the end:
mads-hartmann commentedon Sep 29, 2022
In the dynamic component (here) I had ensured that I created a package with the same name in either case as an attempt to avoid this situation. So I thought that there might be a bug in Leeway where dynamic components weren't evaluated in all conditions. I tried to make a minimal example here but I haven't been able to reproduce the bug yet.
csweichel commentedon Sep 29, 2022
That's smart!
Actually in that case I'd prefer not to merge #103, just to not add this complexity needlessly.
I just tried to reproduce using the steps described by Gero. I have not been able to reproduce this either.
Random thought: this might be some odd dependency on the order of a map. Just thinking that because that's the only thing introducing non-determinism in the linking process.