Classic confinement for yarn

@elopio “alias” in the sense that it’s used here Process for aliases, auto-connections and tracks, not that installing yarn would get you node, just that the node snap would export a top-level yarn command.

@popey is this is the way it works now? There’s nothing preventing a snap with the same name as a top-level alias of another snap existing in the store at the same time? How does prioritisation work with this, is it always the case that the yarn snap would get the yarn command even if it’s installed before the node snap that exports a yarn command?

I was working under the assumption that a top-level alias for one package would preclude a snap from existing in the store with that alias. If this is not the case then I guess it’s not a blocker for us to request a yarn alias for the node package and it then becomes a matter of education and trouble-shooting for users that run into the kinds of problems I’ve mentioned above. My preference would still be for there to be a single yarn available from the store and currently I have the Yarn team agreeing to coordinate with us to manage it through the node snap since we both agree that it makes sense to bundle it together.

Cheers!