Confusion about unplugged packages

[UNLRN]

I've been running a repo with zero-installs and have run into a couple issues that have been solved through looking at issues here. One thing that keeps popping up is the scenario of 'unplugged' packages. The docs say that that:

Packages are unplugged in two cases: either explicitly when the unplugged field is set to true, or implicitly when the package lists postinstall scripts.

And this issue states that most postinstall scripts are actually okay to disable, anyways. So when I see a notification that a package has build scripts, I'll often go double check to make sure they aren't actually needed.

All that makes sense. So I've set enableScripts: false to disable build scripts, which I would assume would prevent packages from becoming unplugged unless explicitly stated. However, I am still getting some packages unplugged. Does this scenario only apply to the direct dependencies postinstall script? For example, if a package I yarn add has a dependency on another package that has a postinstall script, will that package become unplugged? It seems like that' is what I'm noticing happening. (the package in question as a reference)

Is there any way to move forward with a true zero-install repo when a package becomes unplugged if its a dependency of the package? Or will we always have to run the yarn install step so that those individual packages will get added to the target machine?

[merceyz]

There is a third case where packages are unplugged that isn't listed in the docs (will fix that), when a package contains native files Yarn will automatically unplug it as well.

berry/packages/plugin-pnp/sources/jsInstallUtils.ts

Lines 65 to 74 in 344818b

	const FORCED_EXTRACT_FILETYPES = new Set([
	// Windows can't execute exe files inside zip archives
	`.exe`,
	// The c/c++ compiler can't read files from zip archives
	`.h`, `.hh`, `.hpp`, `.c`, `.cc`, `.cpp`,
	// The java runtime can't read files from zip archives
	`.java`, `.jar`,
	// Node opens these through dlopen
	`.node`,
	]);

[arcanis]

Also note that you can always override that using the dependenciesMeta.unplugged field

[UNLRN]

@merceyz Thanks for the additional scenario, that could explain why I'm still seeing some packages get unplugged.

@arcanis Yeah, I saw that field in the docs but I was unsure when to use it. Is there something in particular to look for when overriding the unplugged logic? Or is pretty guaranteed that when the third case is hit, it's required for the package to be unplugged? I'd really like to get to zero-installs but understand if there is a limitation with certain packages needing to be built on the target machines

[arcanis]

It really depends on the package. Some (node-notifier) include a binary within their sources that they need to run properly, in which case unplugging them is the only option. Others have fallbacks on wasm, or include their C/C++ sources for completeness, and in that case unplugging them isn't necessary. Usually it's the former, though.

[UNLRN]

@arcanis Ah, so in the scenarios where you have a package that has to get unplugged, zero-install becomes some-installs? Meaning you can still use the zero-install approach, however you'll have to run yarn install for those packages to get unplugged on target machines (since they aren't included in source and will have to get unzipped in order to function correctly?)

[arcanis]

Yep, exactly!