Open acao opened 1 year ago
@acao note ESLint already enabled for examples, what was an issue in that PR that I added all examples to workspaces
(instead of several ones) and it caused an issue of netlify deploy due hoisting of dependencies (because we use yarn).
Migration to pnpm will solve these issues, but as you said it totally fine to omit to specify examples for workspaces
to boost up speed installing of dependencies.
This is a great topic for next week's working group meeting!
Pls let me know if I can contribute to this task.
@SJ-Kumar hey we are moving along but thank you! I'm not sure if we are ready to nest the examples yet, as we are about to undergo some major tooling changes, but perhaps after?
@jonathanawesome I think this was a great example of where the linting rules clash with what you'd expect examples to do. create-next-app
uses npm, doesn't import React
, and installs everything to dependencies
, and avoids the devDependencies
entirely which is a not uncommon pattern to see these days, as it doesn't really do much unless you're using npm install --production
somewhere.
The next template clashes with our conventions elsewhere, but that shouldn't matter for an example. An example should take whatever the most common stock template and approach is for that bundler/framework (CRA, CNA, etc) and show the minimal implementation from that for certain ends. If we diverge too much from the stock templates for only conventional reasons, people may misinterpret some of those changes as being required (I learned this from experience over the years from questions users asked about our examples).
Now I would still like to move towards the nested examples approach as per graphql-playground
and other projects, but I am happy to start checking some of these examples off the list !
Thanks for your response. I am happy to contribute whenever required.
Recently in #2922 we tried enabling
eslint
for examples again, and it caused many issues. Perhaps we can specify a few more important examples as we do in the workspaces config, which are examples intended for things such asmonaco-graphql
development.We used to build a few examples on
build-demo
script in netlify to validate webpack, parcel, etc other bundlers (incl. type checking in the case of webpack) were working with the npm module, and then a script that ran after to copy the build output to a path in the netlify publishing directory. Eventually we just created a separate netlify deploy for the monaco example but I think we disabled that, and that was using aThe graphiql example is also internal to the workspace - should that just use an example as well?
Or should we move examples into each workspace?
So for example
examples/graphiql-typescript-webpack
examples/graphiql-parcel
examples/graphiql-cdn
examples/graphiql-create-react-app
becomes
packages/graphiql/examples/cdn
packages/graphiql/examples/create-react-app
packages/graphiql/examples/typescript-webpack5
packages/graphiql/examples/webpack5
packages/graphiql/examples/parcel
packages/graphiql/examples/vite
packages/graphiql/examples/vite-typescript
some I'd like to add
packages/graphiql/examples/nextjs
etc
also would be cool to have links to codesandbox/stackblitzes of these examples in the docs
What is the purpose of
build-docs
andbuild-demo
then? What are the goals of this side of the tooling?It's possible that we could switch
build-docs
, which uses typedoc to generate markdown, to run as a pre-commit task, and to check for a diff in CI to ensure the typedocgen commit has been run. or it can be an after-effect workflow on merge.