Add PnP support

[jonahlund]

This commit will add support for users using yarn PnP. Running binaries directly that are normally located in node_modules/.bin doesn't work using PnP. This pr simply checks if PnP is used, and adding 2 extra args to the spawn methods in that case.

[gamedevsam]

This repo provides support for NPM and PNPM, supporting yarn 2 isn't something that is terribly valuable imo (obviously my opinion, but I don't like the direction yarn is going in).

[ghost]

This repo provides support for NPM and PNPM, supporting yarn 2 isn't something that is terribly valuable imo (obviously my opinion, but I don't like the direction yarn is going in).

i respect that. however I do think it would be wise to at minimum not completely exclude pnp users from solid start, because i do think there are plenty of people that are using it/ would like to use it.

[ruler501]

I am a yarn user who wants to be able to use PnP and am looking to migrate to Solid Start. We can probably make it work to just not use PnP but it would definitely hurt our ability to start building with Solid Start.

[patdx]

Yarn 2(+) is a great package manager, even for people who do not want to use the PnP mode. We use it at my work for a few projects in "npm" style mode (nodeLinker: node-modules). I use the built-in interactive upgrade CLI and patch tools all the time and find them irreplaceable. I would like to use the PnP mode more but just depends on compatibility of the base tools.

For PnP mode specifically, considering that the base tools of sold-start (vite, esbuild, rollup) are already compatible with PnP, I think the support would not require much maintenance.

@JonahLund Maybe it would be possible to get PnP support by just merging the existing process.env.NODE_OPTIONS with the extra options provided by the solid CLI. I'm not a heavy PnP user but the following worked for me in a quick test:

{
    ...process.env,
    NODE_OPTIONS: [
      // In PnP mode, the env variable NODE_OPTIONS is
      // preset to something like: "--require .pnp.cjs --experimental-loader .pnp.loader.mjs"
      process.env.NODE_OPTIONS,
      "--experimental-vm-modules",
      inspect ? "--inspect" : undefined,
    ]
      .filter(Boolean)
      .join(" "),
  },
}

If that would work, it would also allow other node options like --max-old-space-size=8192 to be passed to the subprocess and no PnP-specific code required.

[ghost]

Yarn 2(+) is a great package manager, even for people who do not want to use the PnP mode. We use it at my work for a few projects in "npm" style mode (nodeLinker: node-modules). I use the built-in interactive upgrade CLI and patch tools all the time and find them irreplaceable. I would like to use the PnP mode more but just depends on compatibility of the base tools.

For PnP mode specifically, considering that the base tools of sold-start (vite, esbuild, rollup) are already compatible with PnP, I think the support would not require much maintenance.

@JonahLund Maybe it would be possible to get PnP support by just merging the existing process.env.NODE_OPTIONS with the extra options provided by the solid CLI. I'm not a heavy PnP user but the following worked for me in a quick test:

{
    ...process.env,
    NODE_OPTIONS: [
      // In PnP mode, the env variable NODE_OPTIONS is
      // preset to something like: "--require .pnp.cjs --experimental-loader .pnp.loader.mjs"
      process.env.NODE_OPTIONS,
      "--experimental-vm-modules",
      inspect ? "--inspect" : undefined,
    ]
      .filter(Boolean)
      .join(" "),
  },
}

If that would work, it would also allow other node options like --max-old-space-size=8192 to be passed to the subprocess and no PnP-specific code required.

Awesome! got it to work aswell.