PNPM support

[thescientist13]

Type of Change

Feature

Summary

Although pnpm will work with Greenwood, there are a couple issues that have been observed that make the experience a little challenging out of the gate, mostly all related to how pnpm handles installing and managing node_modules (it is very strict!)

This causes a couple related issues:

Transtive Dependencies

There are cases where we showcase using transitive dependencies in our code samples which will fail since pnpm will not install them in the current directory, requiring the use of shamefully-hoist: true

Examples:

• wc-compiler
• @lit-labs/ssr

    ➜  greenwood-lit-ssr git:(pnpm-shoelace-hackathon) ✗ pnpm dev 
> [email protected] dev /Users/owenbuckley/Workspace/github/greenwood-lit-ssr
> greenwood develop

-------------------------------------------------------
Welcome to Greenwood (v0.30.1) ♻️
-------------------------------------------------------
Initializing project config
Initializing project workspace contexts
Generating graph of workspace files...
building from local sources...
node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@lit-labs/ssr' imported from /Users/owenbuckley/Workspace/github/greenwood-lit-ssr/src/pages/api/fragment.js
Did you mean to import @[email protected]/node_modules/@lit-labs/ssr/index.js?
    at new NodeError (node:internal/errors:393:5)
    at packageResolve (node:internal/modules/esm/resolve:860:9)
    at moduleResolve (node:internal/modules/esm/resolve:909:20)
    at defaultResolve (node:internal/modules/esm/resolve:1124:11)
    at nextResolve (node:internal/modules/esm/loader:163:28)
    at ESMLoader.resolve (node:internal/modules/esm/loader:841:30)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:424:18)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:40)
    at link (node:internal/modules/esm/module_job:75:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

  

Import Maps

Another critical issue that comes out of the above behavior is that import map walking will thus fail to resolve any dependencies since it assumes all dependencies are installed into the current directory
https://github.com/ProjectEvergreen/greenwood/blob/v0.30.1/packages/cli/src/lib/walker-package-ranger.js#L118

Details

I think one thing that would essentially unlock help here is working on #684, or otherwise any other places in the CLI where it assumes a specific location for node_modules.

Additionally, we'll need to figure out how to handle how to handle the code samples that reference transitive dependencies that may have to be installed first party, which is a bummer since its nice to be able to rely on the dependency graph of Greenwood specific packages.

---

The current workaround is to manually set shamefully-hoist=true in .npmrc, which we now call out in the Setup docs
https://greenwoodjs.dev/docs/introduction/setup/#install