in a yarn-monorepo, dependencySatisfies is always true when referencing packages in the monorepo

[NullVoxPopuli]

example dep tree:

app-a
├─ dep-base
├─ dep-optional-a
   └─ dep-base
app-b
├─ dep-base    
├─ dep-optional-b
   └─ dep-base
dep-base
└─ (no relavant dependencies)    
dep-optional-a
└─ dep-base
dep-optional-b
└─ dep-base  

in dep-base, I have:

let bag = [];

if (macroCondition(dependencySatisfies('dep-optional-a', '*'))) {
  let stuff = importSync('dep-optional-a/some-path');
  bag.push(...stuff.default);
}


if (macroCondition(dependencySatisfies('dep-optional-b', '*'))) {
  let stuff = importSync('dep-optional-b/some-path');
  bag.push(...stuff.default);
}

console.log( bag );

The intent is to,

• in app-a, have the macroCondition for dep-optional-a be true, and dep-optional-b be false
• in app-b, have the macroCondition for dep-optional-b be true, and dep-optional-a be false

However, what is happening is that all macroConditions are always true, as I get Cannot find module "dep-optional-b" imported from (require) (in app-a, for example)

I would not expect that these conditions would be true, because, for example: app-a, dep-optional-b should not at all be in the dependency tree.

[ef4]

We are following what NPM does here. But I agree that what NPM does is terrible.

I'm OK with adding strictness here. It's a pretty trivial code change. In these two places:

embroider/packages/macros/src/glimmer/dependency-satisfies.ts

Line 31 in 85e6743

let pkg;

embroider/packages/macros/src/babel/dependency-satisfies.ts

Line 34 in 85e6743

let version = packageCache.resolve(packageName.value, us).version;

Before we do packageCache.resolve, we would check us.dependencies for the package name.

[NullVoxPopuli]

I don't think we can close this because the core issue still exists -- the result is different though.
In the above snippet, macroCondition is passed false from dependencySatisfies.
I think you mentioned this elsewhere?, but we need to have the package looked up from the host app somehow?

[ef4]

but we need to have the package looked up from the host app somehow?

This isn't supported, on purpose.

What are you actually trying to do?

[NullVoxPopuli]

What are you actually trying to do?

automate config of dependencies so app devs who don't know the details of what they're doing don't have a potential foot gun.

In the file that is actually trying to do the dependencyContains on dependencies it doesn't declare, the hope was that the addon that has these dependencyContains could detect what related addons an app had installed, and perform some configuration if any of the related addons exist.

however
I am trying out intentionally maybe sometimes unmet peer dependencies to achieve the same result now, but it seems the behavior is the same, dependencySatisfies is false. 🤔
I've been thinking this could work the same as how dependencySatisfies(ember-source, ...) works, but... maybe not?
though, I get false for that, too (in my other issue related to dependencySatisifies)