You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
run yarn build --watch to watch the entire monorepo for changes.
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
run yarn install
run yarn build
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.jsonexports nowadays:
use pnpm instead of yarn
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
replace typescript project references workflow with rush, turborepo or custom nx implementation, moonrepo, etc? many ways to do incremental build/watch
better/up-to date documentation in CONTRIBUTING.md and DEVELOPMENT.md
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
find some way to require changes to package.jsonscripts to require two maintainers to approve, and to also to remind maintainers to update DEVELOPMENT.md when they do.
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
How it used to work
and it could be this simple again or simpler!
Developing graphiql:
yarn install
yarn build --watch
to watch the entire monorepo for changes.yarn start-graphiql
and the dev server starts. This hot reloads when the project referencestsc --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
yarn install
yarn build
yarn build-bundles
is necessary to build the minified production bundles, but is not necessary for development. It builds release bundles forgraphiql
,codemirror-graphql
andvscode-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:build-bundles
, use rollup or esbuild or vite in library mode to ship bundled versions of some libraries likemonaco-graphql
andcodemirror-graphql
, though the default esm we ship for all libraries should be unbundled for obvious reasonspackage.json
scripts
to require two maintainers to approve, and to also to remind maintainers to updateDEVELOPMENT.md
when they do.Steps to get there
The text was updated successfully, but these errors were encountered: