fix: don't unplug required locators that have conditions

[paul-soporan]

What's the problem this PR addresses?

This has been bothering me ever since the conditional dependencies PR was merged and I want to debate it one last time before finally making a decision so that I can tick it off my TODO list. 😄

(A conditional locator is a locator that has conditions and is optional too)

I believe that we should only unplug conditional locators rather than unplugging all locators that have conditions. Reasons:

• Consistency, there's no other place in the codebase where we special-case all packages that have conditions
• It doesn't make sense semantically to unplug all locators that have conditions, as some of them can still work even inside zip archives. There's also the fact that "lists conditions" isn't synonymous with "has native files", a package could simply be written in JS and only do things on one specific platform.

I don't see this one-line change as adding more complexity and I believe that we should try aiming for as much consistency and correctness as possible.

How did you fix it?

By only unplugging locators that are conditional, not required locators that happen to have conditions.

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[arcanis]

Consistency, there's no other place in the codebase where we special-case all packages that have conditions

Conditional dependencies are fairly new, who knows what awaits us 😄

Additionally, I'd argue that this change would make us less consistent, in a very subtle but error-prone way: so far, the unplug mechanism depends entirely on a package itself (if a package foo is unplugged, it's because of its own characteristics). The change you made introduces the dependency tree within the formula computing whether the package should be unplugged or not (since it would depend on whether all the dependents use optionalDependencies).

It's unclear what would be the effects in practice, particularly in terms of DevX - it means a package could switch from being unplugged to not being unplugged from one project to the other, or even within the same one as dependencies are added / removed.

It doesn't make sense semantically to unplug all locators that have conditions, as some of them can still work even inside zip archives. There's also the fact that "lists conditions" isn't synonymous with "has native files", a package could simply be written in JS and only do things on one specific platform.

And not all packages with postinstall scripts, or containing C source code, need to be unplugged - but we do it because it's still very likely to be true.