Improve the developer experience for theme pack / context plugins

[thescientist13]

Currently the workflow for developing and publishing a theme pack is a little clunky, so would be good to track and discuss ways to make this better.

### Development

The main consideration needed for development is that your files won't be in _node_modules, which is what the case would be for users.  So for that reason, we need to add a little biolerplate to _my-theme-pack.js_.  There might be others way to solve it, but it just checks if the packages is installed:
1. If it _is_ installed, then use `__dirname` (which would be inside _node_modules_) as the base path
1. If not installed (like for local development) then use whatever location you have defined in your local repostory.


So using our current example, our final _my-theme-pack.js_ would look like this:
```js
const os = require('os');
const path = require('path');
const packageJson = require('./package.json');
const { spawnSync } = require('child_process');

module.exports = () => [{
  type: 'context',
  name: 'my-theme-pack:context',
  provider: () => {
    const { name } = packageJson;
    const baseDistDir = `node_modules/${name}/dist`;
    const command = os.platform() === 'win32' ? 'npm.cmd' : 'npm';
    const ls = spawnSync(command, ['ls', name]);
    
    const isInstalled = ls.stdout.toString().indexOf('(empty)') < 0;
    const templateLocation = isInstalled
      ? path.join(__dirname, `${baseDistDir}/templates`)
      : path.join(process.cwd(), 'src/templates');

    return {
      templates: [
        templateLocation
      ]
    };
  }
}];
```

And our final _greenwood.config.js_ would look like this
```js
// shared from another test
const myThemePackPlugin = require('./my-theme-pack');
const packageName = require('./package.json').name;
const path = require('path');
const { ResourceInterface } = require('@greenwood/cli/src/lib/resource-interface');

class MyThemePackDevelopmentResource extends ResourceInterface {
  constructor(compilation, options) {
    super(compilation, options);
    this.extensions = ['*'];
  }

  async shouldResolve(url) {
    return Promise.resolve(url.indexOf(`/node_modules/${packageName}/`) >= 0);
  }

  async resolve(url) {
    return Promise.resolve(url.replace(`/node_modules/${packageName}/dist/`, path.join(process.cwd(), '/src/')));
  }
}

module.exports = {
  plugins: [
    ...myThemePackPlugin(),
    {
      type: 'resource',
      name: 'my-theme-pack:resource',
      provider: (compilation, options) => new MyThemePackDevelopmentResource(compilation, options)
    }
  ]
};
```

> _It is a little clunky, so please follow [this discussion](https://github.com/ProjectEvergreen/greenwood/discussions/682) for ways we can try and make this more elegant!_  🙏🏻

[thescientist13]

Yeah, although I wish we could have supported relative paths, if you keep going down, there were some issues 😞
#689 (comment)

If we could make it work though, that would be amazing. Maybe something #691 could help with? 🤔

[thescientist13]

One thing about the isDevelopment flag is that Greenwood will always look in the src/ directory, even when building.

const packageJson = require('./package.json');
const path = require('path');

module.exports = (options = {}) => [{
  type: 'context',
  name: `${packageJson.name}:context`,
  provider: (compilation) => {
    const templateLocation = options.__isDevelopment
      ? path.join(compilation.context.userWorkspace, 'layouts')
      : path.join(__dirname, 'dist/layouts');

    return {
      templates: [
        templateLocation
      ]
    };
  }
}];

Ideally when creating a theme pack and running greenwood build|serve those calls would go to node_modules too.

[thescientist13]

Another observation, when creating the one off development resource there seems to be a discrepancy in how process.env.__GWD_COMMAND__ is getting set, I guess?

process.env.__GWD_COMMAND__ = command;

In the tests I added here I was able to test the command in the resource like this

return Promise.resolve(process.env.__GWD_COMMAND__ === 'develop' ... );

But in my main theme pack repo, I had to add a space?

return Promise.resolve((process.env.__GWD_COMMAND__ === ' develop') ... );

Maybe it's something about how commands are getting passed between npm / yarn in npm scripts? Left the docs to match what I have in my repo just to be safe? 🤷‍♂️

[thescientist13]

Noticed there's also an opportunity to clean up some code added here too as it seems that when theme pack was added and rebased into #674, require.resolve was unable to find the mock "my-theme-pack" and so was failing with an exception

Error: Cannot find module 'my-theme-pack'
Require stack:
- /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/plugins/resource/plugin-node-modules.js
- /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/config.js
- /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/compile.js
- /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/commands/build.js
- /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/index.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:880:15)
    at Function.resolve (internal/modules/cjs/helpers.js:94:19)
    at NodeModulesResource.resolve (/Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/plugins/resource/plugin-node-modules.js:29:85)
    at /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/serve.js:4:421
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/serve.js:4:216
    at async /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/serve.js:4:216
    at async /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/serve.js:4:216
    at async /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/serve.js:4:216
    at async /Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/serve.js:4:216 {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/plugins/resource/plugin-node-modules.js',
    '/Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/config.js',
    '/Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/lifecycles/compile.js',
    '/Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/commands/build.js',
    '/Users/owenbuckley/Workspace/project-evergreen/repos/greenwood/packages/cli/src/index.js'
  ]
}

So had to add a fallback in that case, to what our prior logic was, just to be safe.

---

Would be nice to find a way to make sure this can interop nicely with our (Theme Pack) tests so we can remove this, although I suppose leaving the error handling in is fine.

[thescientist13]

Another opportunity to improve things for Greenwood, not so much developers, is in order to support #674 , we needed to add a work around for Theme Packs specifically. Maybe there could be a way to eliminate this, possibly in conjunction with #691 ?

[thescientist13]

Even after the v0.27.0 upgrade, for theme packs it seems, like the [greenwood-starter-presentation[(https://github.com/thescientist13/greenwood-starter-presentation) for some reason aren't bundling <style> tags in markdown files?

thescientist13/greenwood-starter-presentation#63