Skip to content

Add notes from May #132

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

Merged
merged 1 commit into from
Jul 11, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions notes/2024/2024-05.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
# GraphQL WG Notes - May 2024

**Watch the replays:**
[GraphQL.js Working Group Meetings on YouTube](https://www.youtube.com/playlist?list=PLP1igyLx8foHghwopNuQM7weyP5jR147I)

- [Agenda link](https://github.com/graphql/graphql-js-wg/blob/main/agendas/2024/05-May/29-graphql-js-wg-may-2024.md)
- Intros, agreement, etc.
- Agenda item: Call for reviews (Jovi)
- [Fragment arguments PR](https://github.com/graphql/graphql-js/pull/4015) - split up into parse/execute/typeInfo
- [Process.env changes in v16](https://github.com/graphql/graphql-js/pull/4022)
- Agenda item: Collection of libraries and how they import from graphql (Lenz)
- Considering bundling changes in v17 (discussed in April meeting)
- Avoiding dual package hazard, release current v17 alpha as v18
- Benjie noted that he wasn’t sure which exports are guaranteed documented exports
- We explored which ones are used by the community
- Changes introduce an exports field - missing file means breaking imports
- Assumption was that importing from the root would be enough
- Currently package guarantees that you can import from folders
- Individual files are not officially guaranteed
- Issue [https://github.com/graphql/graphql-js/issues/4074](https://github.com/graphql/graphql-js/issues/4074)
- Pinged maintainers and brought up into the GraphQL WG
- Participating libraries said to be okay with just importing from the root
- A lot of them import TypeScript types that aren’t really exported
- Most of them are simple types
- Jovi: maybe we should leverage GitHub code search to reach out rather than wait for input
- Phil: we collected a similar import-map for modular-graphql, which brought us to a similar conclusion that only root/folders are used.
- Phil: biggest concern are libraries that aren’t maintained but still in use, folks have to explicitly indicate that they support graphql v17
- Phil: [https://github.com/0no-co/babel-plugin-modular-graphql](https://github.com/0no-co/babel-plugin-modular-graphql)
- Lenz: can import types that are marked internal deeply
- Phil: the Maybe/Map type shouldn’t be exposed, they are simple and won’t change
- Suggested path forward: leave issue open and move forward with leaving the folders as an export-map
- Agenda item: Implement bundling changes (Lenz)
- [Open pull request](https://github.com/graphql/graphql-js/pull/4096)
- Next week will be ready for review
- Phil: “module” field isn’t official in the package.json - so I can see why vite and vitest behave differently
- Lenz: you need different conditions for the types to have `mts` and `ts` because TS will start complaining in the future
- Lenz: this pattern is established by very popular libraries, seen in Redux-Saga/Emotion/…
- Phil: not to disqualify the credibility of who apply this pattern - there are a lot of packages that have more downloads and I can’t see everyone applying these changes
- Phil: in urql and many other libraries we have explored solutions to this. By definition there can still be a dual package hazard as we can have duplicate installations. GraphQL would complain because of the `instanceof` check.
- Phil: general concern, we are trying to fix libraries that are refusing to fix themselves
- Lenz: my main concern is that right now it’s impossible to test GraphQL libraries - removing `instance`of is a lot more effort.
- Agenda item: process.env, globalThis, and typeof process (Lenz)
- This ties into the point above, it would be better served by removing `instanceof` action item for Phil to create a proposal
-
- We can fix this in GraphQL 16 so people can upgrade by reverting, using `typeof process` or `globalThis.process`
- Meeting decision: `globalThis.process`
- We’ll need accompanying documentation for bundlers, apollo already has this
- Action items are transferred to the wg/issues
7 changes: 6 additions & 1 deletion notes/2024/2024-06.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,13 @@
# GraphQL WG Notes - June 2024

**Watch the replays:**
[GraphQL.js Working Group Meetings on YouTube](https://www.youtube.com/playlist?list=PLP1igyLx8foHghwopNuQM7weyP5jR147I)

- Intros, agreement, note taking volunteers and agenda review
- Previous meeting action items
- Updating the typeof process PR https://github.com/graphql/graphql-js-wg/issues/123
- Cleaning up bundling changes https://github.com/graphql/graphql-js-wg/issues/124
- Alternative proposal to remove instanceof checks https://github.com/graphql/graphql-js-wg/issues/125
- Alternative proposal to remove instanceof checks https://github.com/graphql/graphql-js-wg/issues/125
- Proposal: change default branch to 16.x.x (5m, Benjie)
- Benjie: Main has been the WIP for GraphQL.JS 17 for a while
- Benjie: Reason for that being incremental delivery being the big release
Expand Down