Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[redesign] editor in new design #2513
[redesign] editor in new design #2513
Changes from 14 commits
903c772
e947193
c37be13
d149789
2c68448
c47aaac
04ef5a0
e1992e7
1cabfbd
3ea62ee
cbde0c3
db2c34e
8db0e72
1ca5160
8c5864c
c82b22f
218c261
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
initialVersions
here should begraphiql
,@graphiql/react
,codemirror-graphql
and@graphiql/toolkit
only.I imagine the changests CLI added all of these just because they had active diffs or changes, but there is no reason the language service, server, cli, monaco-graphql, vscode-graphql, or any of these examples need to go into pre-release for these changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just gave this a test run locally to see what
changeset
would do in that case. Turns out that you can't use pre-releases for a subset of packages, it's either all or nothing. So when we'd merge this we'd also force pre-releases onvscode-graphql
etc 😕An alternate way of doing this could be to just have a dedicated branch where we start merging the approved PRs into. Once we have everything we need for v2 we merge this one big PR into
main
and release it. Wdyt?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well my first reaction is remembering the pain of dedicated branch we had in 20202 (1.x at the time, and 2.x was main, but then that became the retired rfc branch and 1.x became main again), because then the main and dedicated branch got terribly out of sync! we were issuing 1.x releases from one branch and 2.x from
main
.that said, I think your idea will work out fine as long as we don't make any changes to the graphiql packages from main while this branch exists, and the plan is to merge it back into
main
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I also don't really favor this approach, but I don't see a better option 😕 (I also hope that we can get all of this done within the next couple of weeks, so this branch won't be around for a longer time 🤞 )
Then let's do it like this! I'll create a branch
graphiql-v2
where we'll merge all the breaking changes and the new design into. Once we reviewed and collected everthing we'll merge this branch intomain
. I'll also rebase the branch regularly so that it won't get out of sync and doesn't block other PRs being merged intomain
in the meantime.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like for maintainers such as @yoshiakis and @imolorhe to be able to review this change, to make sure that it doesn't clash with other popular
codemirror-graphql
implementations outside ofgraphiql
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense! This would be a new major version for
codemirror-graphql
, so it would not break any dependents. Still good to know if this would be blocking others to update to this new version in any way.@yoshiakis @imolorhe to sum up the changes for easy digestion:
MyType.myField
->myField
MyType.myField(myArg: MyArgType)
->myArg: MyArgType
div
div
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also CCing @stonexer @benjie @sgrove and others who might be interested in this conversation!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Considering this is going to be a major version , should not be a problem. Is there a way to tag BREAKING CHANGEs in changeset? If so, this should be tagged as such.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@imolorhe yes, essentially just by making it a major version change and adding the equivalent conventional-commits style breaking change note in bold in the changeset markdown! Then it will appear in the gh release and in the changelog
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this will show up in the changelog! I also made the changeset message more elaborate and added the bullets from my comment above.
Large diffs are not rendered by default.
Large diffs are not rendered by default.