Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monorepo Tooling SOS Roadmap #2639

Open
acao opened this issue Aug 7, 2022 · 0 comments
Open

Monorepo Tooling SOS Roadmap #2639

acao opened this issue Aug 7, 2022 · 0 comments
Labels

Comments

@acao
Copy link
Member

acao commented Aug 7, 2022

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? fix project references, upgrade @types/graphql #2497
  2. also, for this to work, we need to fix our graphql version issue via update to GraphQL 17 #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 draft: merge webpack to vite #2371 Add vite build #2638 , etc - we should
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant