fix: add preferUnplugged to package.json

[slainless]

Problem

Right now, the default behaviour of tinypool with child process runtime will always break in yarn PnP environment. End-user can either mark this package as unplugged to let fork resolves process.js correctly with builtin node module resolution or pass NODE_OPTIONS to Tinypool constructor options (and by extension, to child_process.fork()) to allow it to resolve process.js with yarn PnP resolution.

Reproduction

https://github.com/slainless/tinypool-reproduction

To fix the reproduction, just run yarn unplug tinypool.

To test preferUnplugged on distribution:

1. Add the flag to local tinypool repository
2. Build & pack
3. yarn link to local tinypool from repro repository then change protocol from portal: to file:
4. yarn install
5. It should install as unplugged by default

Solution

The most unobstrusive fix is to mark tinypool as preferUnplugged. This should fix the default child process runtime behaviour in yarn PnP environment and release end-user from responsibility of passing NODE_OPTIONS or marking it as unplugged per project basis.

The actual motivation for this PR is actually to unblock oxc integration (which uses tinypool):

• feat: Add editor SDK support for oxc (oxfmt & oxlint) yarnpkg/berry#7078

[clemyan]

child_process.fork() does work with Yarn PnP, but to do so the child process must inherit the NODE_OPTIONS environment variable. See #59 (comment)

[slainless]

child_process.fork() does work with Yarn PnP, but to do so the child process must inherit the NODE_OPTIONS environment variable. See #59 (comment)

Thanks for the clarification, I have updated my statement.

[AriPerkkio]

Looking at version 0.0.1, Tinypool has never passed process.env to workers or processes implicitly:

tinypool/src/index.ts

Lines 598 to 599 in adbffcd

	const worker = new Worker(resolve(__dirname, "./worker.js"), {
	env: this.options.env,

I really don't want to add any PnP related logic in this package.

[slainless]

@AriPerkkio Fair enough. That’s why I’m proposing adding support for the package’s default behavior under Yarn PnP via preferUnplugged. At the very least, I want it to work with the default Node module resolution out of the box.

[AriPerkkio]

child_process.fork() does work with Yarn PnP, but to do so the child process must inherit the NODE_OPTIONS environment variable. See #59 (comment)

oxfmt, that this fix is related to (?) already passes process.env. Are you sure this is what's wrong?

https://github.com/oxc-project/oxc/blob/d480bfed3e8900f57a9ed0948f44557281a39729/apps/oxfmt/src-js/cli/worker-proxy.ts#L23-L24

[slainless]

oxfmt, that this fix is related to (?) already passes process.env. Are you sure this is what's wrong?

https://github.com/oxc-project/oxc/blob/d480bfed3e8900f57a9ed0948f44557281a39729/apps/oxfmt/src-js/cli/worker-proxy.ts#L23-L24

Yes, I missed that part. After taking a closer look, the issue actually comes from the fact that tinypool is esm and the child_process fork by extension uses esm module resolution. The setupEnv from yarnpkg/sdks is missing --loader flag so the resolution fail.

This means the issue in that PR can likely be fixed entirely on that side, so this PR may not be necessary.

That said, the main point of this PR still stands but I’m fine with closing it if you prefer that.

[AriPerkkio]

The setupEnv from yarnpkg/sdks is missing --loader flag so the resolution fail.

As this sounds like it's an ESM related issue on Yarn PnP side, I don't think adding package manager feature specific work-arounds in downstream packages is good idea.

And as this is not related to the earlier discussed process.env.NODE_OPTIONS in any way, let's close this PR without merging.

[clemyan]

oxfmt, that this fix is related to (?) already passes process.env. Are you sure this is what's wrong?

Ah yes, I missed that.

I still think the fact that process.env is not inherited by default should be documenterd

[AriPerkkio]

I agree. No idea why piscina didn't inherit it by default. Maybe they had good reason in piscinajs/piscina#26.