|
| 1 | +# Meeting Summary for GraphQL.js Working Group meeting |
| 2 | + |
| 3 | +**NOTICE**: This summary was auto-generated by Zoom's "AI". AI-generated |
| 4 | +content may be inaccurate or misleading. Always check for accuracy. If in |
| 5 | +doubt, please consult the meeting recording at |
| 6 | +https://youtube.com/@GraphQLFoundation/playlists |
| 7 | + |
| 8 | +- Meeting start: 2025-06-25T16:55:54Z |
| 9 | +- Meeting end: 2025-06-25T18:22:03Z |
| 10 | +- Summary start: 2025-06-25T16:58:29Z |
| 11 | +- Summary end: 2025-06-25T18:21:20Z |
| 12 | + |
| 13 | +The GraphQL.js working group meeting focused on discussing JavaScript module design and the transition to ESM-only support, with Jayden presenting proposals for restructuring the GraphQL.js library to improve performance and reduce unnecessary code loading. The team explored various approaches to handling module imports, including deep imports and conditional exports, while considering browser compatibility and developer experience. The conversation ended with plans to create a tracking issue for proposed changes and coordinate further via GitHub, with an emphasis on gathering maintainers' buy-in and addressing potential migration challenges. |
| 14 | + |
| 15 | +## Next Steps |
| 16 | + |
| 17 | +- Jayden to raise an issue on GitHub articulating the proposals for optimal module design and Esm migration, including next steps and potential challenges with existing PRs. |
| 18 | +- Yaacov to integrate feedback from Lens on development and production checks, create a PR, and ping Jayden for review. |
| 19 | +- Maintainers to assess and categorize existing PRs to determine which can be closed or need to be kept open. |
| 20 | +- Yaacov to create a discussion or issue to gather buy-in from all maintainers, especially Yovie, regarding the proposed changes. |
| 21 | +- Jayden to assist with pure ESM topics and implementation moving forward. |
| 22 | + |
| 23 | +## Summary |
| 24 | + |
| 25 | +### GraphQL.js Working Group Meeting |
| 26 | + |
| 27 | +The GraphQL.js working group meeting began with Yaacov explaining that he had removed a specific proposal about package exports from the agenda due to feedback received offline from Lens. Jayden presented his topic on optimal JavaScript module design, which was motivated by its connection to Yaacov's agenda item about ESM-only module support and CGS fallbacks. The meeting included introductions from all participants, including Benjie, Dennis, and Jayden, and established that notes would be taken both manually and by AI to document the discussion. |
| 28 | + |
| 29 | +### JavaScript Module Structure Optimization |
| 30 | + |
| 31 | +Jayden discussed the optimal structure for JavaScript modules, advocating for single exports per module and the avoidance of barrel files and index modules. He explained that this approach can improve minification and reduce unnecessary file caching, particularly in Deno backend environments. Jayden suggested restructuring the GraphQL.js library by extracting publicly exported entities into separate modules, which would allow for more efficient imports and reduce the need to download and cache large amounts of unnecessary code. |
| 32 | + |
| 33 | +### ESM Transition in GraphQL.js |
| 34 | + |
| 35 | +Jayden discussed the challenges of managing ESM and CommonJS versions in GraphQL.js, emphasizing the need for a pure ESM approach to improve performance and reduce friction. He proposed removing the main entry point and deep imports to force correct usage, which would require explicit package.json exports. Denis raised concerns about the potential for a large number of files and a "waterfall effect" when splitting exports, but Jayden explained that deep imports would be more performant by avoiding unnecessary loading steps. |
| 36 | + |
| 37 | +### Single File Export Benefits and Drawbacks |
| 38 | + |
| 39 | +Denis and Jayden discussed the benefits and drawbacks of having one file per export in a project. Jayden shared his experience with enforcing this practice through an ESLint plugin and its positive impact on project navigation and maintenance. Denis raised concerns about the potential for increased network activity and file size with this approach. They also touched on the possibility of automating the process to some extent. The discussion concluded with an overview of a proposed conditional exports scheme for handling different import scenarios. |
| 40 | + |
| 41 | +### GraphQL Import Pattern Discussion |
| 42 | + |
| 43 | +Jayden and Denis discussed the importance of maintaining a main entry point in the GraphQL package for browser compatibility and developer experience, while Benjie highlighted the trade-offs of deep imports, including discoverability and tree-style browsing. Jayden emphasized the need for a consistent import pattern to ensure reliability across the ecosystem, while Benjie acknowledged the pain points of unnecessary imports but suggested that deep imports could offer benefits like auto-completion and browsing. The group agreed on the importance of optimizing GraphQL.js for ecosystem reliability, but no final decision was made on the specific import approach. |
| 44 | + |
| 45 | +### ES Modules Transition Discussion |
| 46 | + |
| 47 | +The team discussed the challenges and potential solutions for transitioning to ES modules in GraphQL.js. Jayden and Yaacov explored the idea of an intermediate major version release that maintains the current API while restructuring the codebase internally, but Jayden expressed concerns about the logistical challenges of such a change, including potential conflicts with ongoing PRs and the need for buy-in from the community. Yaacov suggested creating a PR to demonstrate the proposed changes, but Jayden emphasized the importance of having a clear plan and agreement on the ideal directory structure before proceeding. The team acknowledged the technical ability to manage the transition with aliasing and mapping, but Jayden advised against creating a discrepancy between the package exports and physical directory structure. |
| 48 | + |
| 49 | +### GraphQL Import Restructuring Discussion |
| 50 | + |
| 51 | +Jayden and Denis discussed the implications of restructuring GraphQL imports in a Node.js project, focusing on browser performance and code organization. Denis presented data showing that importing all necessary files could result in a large number of requests, but Jayden argued that modern browsers handle multiple parallel requests efficiently and that unused code is a common issue across web applications. They agreed that while removing index files might improve tree shaking, it could also require significant migration efforts and might not be backward compatible, particularly for peer dependencies. |
| 52 | + |
| 53 | +### GraphQL Modernization and Migration Plans |
| 54 | + |
| 55 | +The team discussed modernizing the GraphQL stack, with Jayden presenting proposals for handling ESM and module design changes. Yaacov suggested creating a tracking issue to document the proposed changes and gather buy-in from maintainers, while also addressing the need to assess and potentially close old pull requests. Jayden agreed to raise a high-quality issue within the next few days, separating proposals by controversy scale and outlining next steps, including a potential lockdown on new PRs during the module migration. Yaacov expressed gratitude for Jayden's willingness to contribute to both ESM and POE topics, and the conversation ended with plans to coordinate further via GitHub. |
0 commit comments