graphiql icon indicating copy to clipboard operation
graphiql copied to clipboard

Monorepo Tooling SOS Roadmap

Open acao opened this issue 3 years ago • 0 comments

How it used to work

and it could be this simple again or simpler!

Developing graphiql:

  1. clone the monorepo
  2. run yarn install
  3. run yarn build --watch to watch the entire monorepo for changes.
  4. in another terminal run yarn start-graphiql and the dev server starts. This hot reloads when the project references tsc --build --watch incrementally rebuilds on any change to any project in the workspace.

Developing vscode-graphql

repeat steps 1-3 4. run the launcher

Releasing the monorepo

  1. run yarn install
  2. run yarn build
  3. yarn build-bundles is necessary to build the minified production bundles, but is not necessary for development. It builds release bundles for graphiql, codemirror-graphql and vscode-graphql.

The key to simplicity in this monorepo was the methdology that all scripts be run from the root. Once monorepos require working from scripts from individual workspaces, it becomes much more complicated, and at worst suffers from the monorepo "death by a thousand cuts" dillema we are starting to see here. Any scripts defined at the individual workplace level were meant to be run in bulk or selectively from the root.

How i would like it to change from how it used to be

This was an easier setup in some regards but had it's drawbacks. Changes I would like to make, some of which because we have package.json exports nowadays:

  1. use pnpm instead of yarn
  2. on build-bundles, use rollup or esbuild or vite in library mode to ship bundled versions of some libraries like monaco-graphql and codemirror-graphql, though the default esm we ship for all libraries should be unbundled for obvious reasons
  3. replace typescript project references workflow with rush, turborepo or custom nx implementation, moonrepo, etc? many ways to do incremental build/watch
  4. better/up-to date documentation in CONTRIBUTING.md and DEVELOPMENT.md
  5. obviously replace webpack 4 with vite. the webpack examples should be upgraded to webpack 5, but only vite examples will be included in the workspaces now
  6. find some way to require changes to package.json scripts to require two maintainers to approve, and to also to remind maintainers to update DEVELOPMENT.md when they do.

Steps to get there

  1. restore/replace typescript project references for simple global repo build & watch? #2497
  2. also, for this to work, we need to fix our graphql version issue via #2439. currently the package boundary kerfuffle allows us to accidentally bypass this, but once we simplify things this shows up
  3. Switch from webpack to vite for graphiql cdn builds #2371 #2638 , etc - we should

acao avatar Aug 07 '22 07:08 acao