graphql
GraphiQL Plugins (2.0.0-beta.0) Meta Issue
This is a meta-issue for the GraphiQL IDE plugins effort, towards the GraphQL 2.0.0 beta milestone
(Note: this was previously marked as [email protected], however we decided that [email protected] should be the last officially stable release before merging all of these breaking changes)
:construction_worker_woman: Work In Progress
Preceding initiatives that already have merged or in-progress PR(s) (will try to keep this updated, but projects listed here are your best bet)
Get involved or ask questions via our discord channel
- [x] React Context Refactor - #1468 - this is essentially the Plugin RFC API
- [x] Add Monaco to GraphiQL - acao/graphiql/pull/17 - yep you read it! replacing codemirror with monaco, merging it to #1468 when it's ready!
- [x] New GraphiQL Components/Theme/Layout System - @walaura did some excellent work setting up new components and a system for themeing and layout, if anyone wants to help her advance this effort they are more than welcome! See
packages/graphiql/src/new-componentsfor more details and readmes. Will add more proposal spec for components to add soon!
:world_map: Dependent Roadmaps
These are roadmaps that will see to the introduction of a stable plugin API for GraphiQL 2.0.0. All of these are in progress.
See the visual roadmap here! https://miro.com/app/board/o9J_ktmGZck=/
- GraphiQL 2.0.0-beta Roadmap - #1446
- Baseline Monaco Mode - #1445 (Demo)
- LSP 3.0.0-beta Roadmap - #1447
:clipboard: Github Projects
These are where most of the work is organized. Issues and cards that often become issues. An issue might belong to two projects.
- Feature Roundup - organize requested features into core/contrib/etc, proof out new ones as cards that become issues
- [x] Webpack Takeover - replace browserify with webpack, modernize babel, add esm exports, and more!
- [x] Convert to Typescript - completed except codemirror mode, which will not be used for this effort.
- [x] GraphiQL Context API Refactor (in progress): replace state implementation with context or another state management system, introduce replacement/new API interfaces.
- [x] Monaco GraphQL first release (in progress): create a monaco mode that satisifies most baseline criteria, and change/refactor LSP as necessary
- [x] Component Library and Layout Ecosystem
- [ ] Complete Plugin API Spec - need to add to this! A catch-all project for discussion/RFCs/spec proposals
:speech_balloon: Discussions
These discussions will need to be turn into proposals/RFCs. In the case of the first discussion, it could lead to dozens of RFCs.
- Interface for a GraphiQL plugin - #829 - Plugin API interface discussion
- Redesign for Plugins - #978 - new full-fledged UX Design re-work via @orta!
-
Editor and Documentation Accessibility - #954 - essential that new redesign is accessibility first, and that
[email protected]stable is as accessible as it's dependencies allow.
:bulb: Proposals
These proposals need to be advanced, as well as any issue labelled potential plugin needs to either be closed and associated with a proposal, or turned into a full proposal/RFC.
- Working Plugin API Proposal (NotionHQ document) - open for comment! This will be reviewed at the April GraphiQL working group meeting.
-
API Breakages - #1165 - Proposed API breakages, many of which are already present in
[email protected] - Your proposals! - Please provide PRs and issues, and we will track them with the GraphiQL Plugin Spec project. Templates coming soon.
Note: Projects prefixed with ! are for organizing purposes, where the lanes don't represent states (such as features roundup)
@orta thanks for all your awesome updates and the graphic! I'm going to add some more items and start cross-referencing issues in the queue today. See, about starting to break things up!
there is still so much to add to this! @orta had the great idea of breaking out, which we’ve done with github projects. please sort them alphabetically to see the order of precedence.
in fact, we just closed a project for the first time! (Webpack Takeover). It feels real nice to close a roadmap!
Hello @orta I would love to work on graphql service by starting to convert in Typescript.
@moulikcipherX good news, we've already converted it to typescript! about to schedule new working group schedule and Plugin API spec proposals here soon!
@orta re-opening this to turn it into a mega-issue (which can summarize and cross-reference gh projects), adding plugins as well?
Hello @orta I would love to work on graphql service by starting to convert in Typescript.
graphql language service conversion was completed last year, but thank you though!
plugins made 2.0 architecture too complicated for the next major version, and also I'm no longer being paid to work on this monorepo as of this fall, so the roadmap has changed based on my availability.
because I'm one of the only active maintainers for this ecosystem, I mostly only have time for the minimum - maintenance work, advancing new GraphQL features so we can advance the spec, and ensuring the LSP ecosystem supports all GraphQL features fully.
there is a WIP for 2.0 since early this year. it was merged to master branch, then we moved it to a seperate workspace because of performance issues with context. the readme will be updated with more details soon, and I've been trying to recruit folks to offer new proposals to finish 2.x and no one has opened a PR. i have a lot more community/devrel work to do. was hoping for hacktober, but at work I was pivoted to work on wordpress plugins well before I could make that deadline.
most of the time I spent being paid to work on this repo, I spent on monaco-graphql which is a requirement for 2.0, supporting [email protected], and advancing more complete LSP support for 2.0.
Modified Goals for 2.0.0
Instead of plugins, for 2.0, we will just have fantastic components, hooks and state implementation (an SDK so to speak, for advanced custom implementations) and an optional top-level service layer GraphiQL component and middlewares. Hopefully sometime soon I can re-hash all the architectural plans, but at this point, there are too many pressing issues and features to address in this repo outside of the graphiql workspace.
The end goal here is not plugins, but enhanced customizeability and extensibility. Plugins are a way to get there, but powerful user interfaces and consistent configuration patterns can lead to plugin-like capabilities.
Since we already need to rewrite the entire clientside domain model with a new state management tool (yet to be chosen), adding the complexity of an entire plugin API isn't worth it, when people can just publish react components and libraries that can be imported to new and powerful component props, and thus be passed to monaco, to xstate or redux or whatever state manager, or components to be rendered in various regions. The monaco editor itself covers so so many requested GraphiQL features (that are still open issues) that codemirror just doesn't have.
Then, this 2.0 SDK will change for 3.0 to some degree, and potentially a plugin service layer will be introduced on top of that.
What you can do now
If you want a full-featured, open source client that uses GraphQL and supports a rich plugin ecosystem now, Altair and Insomnia are both excellent choices for this.
If you want to build your own tool with a plugin ecosystem with react, svelte, vue, plain js, whatever you choose, check out the github api explorer demo we have for monaco-graphql!
I've come up with a "fork" on the architectural design for this effort
https://github.com/graphql/graphiql/discussions/1787
we're also writing a WIP roadmap (and yes, anyone is able to edit it!)
help with roadmapping
if you want to help advance the roadmapping effort, and help reduce the issue count at the same time, look for issues labelled "plugin", or at any other feature requests, and add them to the GraphiQL 2.0 roadmap. you may need to formulate a summary of the issue and what it represents.
once an feature request has been added to the roadmap, you can add @acao #roadmapped at the end of the comment, and I can do a strict issue search for all of them. this would help me so much!
we're open to any improvements to this process