Skip to content
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

Version Packages #3603

Merged
merged 1 commit into from
May 31, 2024
Merged

Version Packages #3603

merged 1 commit into from
May 31, 2024

Conversation

acao
Copy link
Member

@acao acao commented May 14, 2024

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

[email protected]

Minor Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fix many schema and fragment lifecycle issues, not all of them, but many related to cacheing. Note: this makes cacheSchemaForLookup enabled by default again for schema first contexts.

    This fixes multiple cacheing bugs, upon addomg some in-depth integration test coverage for the LSP server. It also solves several bugs regarding loading config types, and properly restarts the server and invalidates schema when there are config changes.

    Bugfix Summary

    • configurable polling updates for network and other code first schema configuration, set to a 30s interval by default. powered by schemaCacheTTL which can be configured in the IDE settings (vscode, nvim) or in the graphql config file. (1)
    • jump to definition in embedded files offset bug, for both fragments and code files with SDL strings
    • cache invalidation for fragments (fragment lookup/autcoomplete data is more accurate, but incomplete/invalid fragments still do not autocomplete or validate, and remember fragment options always filter/validate by the on type!)
    • schema cache invalidation for schema files - schema updates as you change the SDL files, and the generated file for code first by the schemaCacheTTL setting
    • schema definition lookups & autocomplete crossing over into the wrong project

    Notes

    1. If possible, configuring for your locally running framework or a schema registry client to handle schema updates and output to a schema.graphql or introspection.json will always provide a better experience. many graphql frameworks have this built in! Otherwise, we must use this new lazy polling approach if you provide a url schema (this includes both introspection URLs and remote file URLs, and the combination of these).

    Known Bugs Fixed

    Test Improvements

    • new, high level integration spec suite for the LSP with a matching test utility
    • more unit test coverage
    • total increased test coverage of about 25% in the LSP server codebase.
    • many "happy paths" covered for both schema and code first contexts
    • many bugs revealed (and their source)

    What's next?

    Another stage of the rewrite is already almost ready. This will fix even more bugs and improve memory usage, eliminate redundant parsing and ensure that graphql config's loaders do all of the parsing and heavy lifting, thus honoring all the configs as well. It also significantly reduces the code complexity.

    There is also a plan to match Relay LSP's lookup config for either IDE (vscode, nvm, etc) settings as they provide, or by loading modules into your graphql-config!

Patch Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:

    • restores completion for object and input type fields when the document context is not detectable or parseable
    • correct top-level completions for either of the unknown, type system or executable definitions. this leads to mixed top level completions when the document is unparseable, but now you are not seemingly restricted to only executable top level definitions
    • .graphqls ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown
  • #3521 aa6dbbb4 Thanks @acao! - Introduce locateCommand based on Relay LSP pathToLocateCommand:

    Now with <graphql config>.extensions.languageService.locateCommand, you can specify either the existing signature for relay, with the same callback parameters and return signature (of a string delimited by : characters), or you can return an object with {uri, range} for the exact set of coordinates for the destination range. the function can be sync or async.

    Relay LSP currently supports Type and Type.field for the 2nd argument. Ours also returns Type.field(argument) as a point of reference. It works with object types, input types, fragments, executable definitions and their fields, and should work for directive definitions as well.

    In the case of unnamed types such as fragment spreads, they return the name of the implemented type currently, but I'm curious what users prefer here. I assumed that some people may want to not be limited to only using this for SDL type definition lookups. Also look soon to see locateCommand support added for symbols, outline, and coming references and implementations.

    The module at the path you specify in relay LSP for pathToLocateCommand should work as such.

    // import it
    import { locateCommand } from './graphql/tooling/lsp/locate.js';
    export default {
      languageService: {
        locateCommand,
      },
    
      projects: {
        a: {
          schema: 'https://localhost:8000/graphql',
          documents: './a/**/*.{ts,tsx,jsx,js,graphql}',
        },
        b: {
          schema: './schema/ascode.ts',
          documents: './b/**/*.{ts,tsx,jsx,js,graphql}',
        },
      },
    };
    // or define it inline
    
    import { type LocateCommand } from 'graphql-language-service-server';
    
    // relay LSP style
    const locateCommand = (projectName: string, typePath: string) => {
      const { path, startLine, endLine } = ourLookupUtility(
        projectName,
        typePath,
      );
      return `${path}:${startLine}:${endLine}`;
    };
    
    // an example with our alternative return signature
    const locateCommand: LocateCommand = (projectName, typePath, info) => {
      // pass more info, such as GraphQLType with the ast node. info.project is also available if you need it
      const { path, range } = ourLookupUtility(
        projectName,
        typePath,
        info.type.node,
      );
      return { uri: path, range }; // range.start.line/range.end.line
    };
    
    export default {
      languageService: {
        locateCommand,
      },
      schema: 'https://localhost:8000/graphql',
      documents: './**/*.{ts,tsx,jsx,js,graphql}',
    };

    Passing a string as a module path to resolve is coming in a follow-up release. Then it can be used with .yml, .toml, .json, package.json#graphql, etc

    For now this was a quick baseline for a feature asked for in multiple channels!

    Let us know how this works, and about any other interoperability improvements between our graphql LSP and other language servers (relay, intellij, etc) used by you and colleauges in your engineering organisations. We are trying our best to keep up with the awesome innovations they have 👀!

  • Updated dependencies [aa6dbbb4, aa6dbbb4, aa6dbbb4]:

[email protected]

Minor Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fix many schema and fragment lifecycle issues, not all of them, but many related to cacheing. Note: this makes cacheSchemaForLookup enabled by default again for schema first contexts.

    This fixes multiple cacheing bugs, upon addomg some in-depth integration test coverage for the LSP server. It also solves several bugs regarding loading config types, and properly restarts the server and invalidates schema when there are config changes.

    Bugfix Summary

    • configurable polling updates for network and other code first schema configuration, set to a 30s interval by default. powered by schemaCacheTTL which can be configured in the IDE settings (vscode, nvim) or in the graphql config file. (1)
    • jump to definition in embedded files offset bug, for both fragments and code files with SDL strings
    • cache invalidation for fragments (fragment lookup/autcoomplete data is more accurate, but incomplete/invalid fragments still do not autocomplete or validate, and remember fragment options always filter/validate by the on type!)
    • schema cache invalidation for schema files - schema updates as you change the SDL files, and the generated file for code first by the schemaCacheTTL setting
    • schema definition lookups & autocomplete crossing over into the wrong project

    Notes

    1. If possible, configuring for your locally running framework or a schema registry client to handle schema updates and output to a schema.graphql or introspection.json will always provide a better experience. many graphql frameworks have this built in! Otherwise, we must use this new lazy polling approach if you provide a url schema (this includes both introspection URLs and remote file URLs, and the combination of these).

    Known Bugs Fixed

    Test Improvements

    • new, high level integration spec suite for the LSP with a matching test utility
    • more unit test coverage
    • total increased test coverage of about 25% in the LSP server codebase.
    • many "happy paths" covered for both schema and code first contexts
    • many bugs revealed (and their source)

    What's next?

    Another stage of the rewrite is already almost ready. This will fix even more bugs and improve memory usage, eliminate redundant parsing and ensure that graphql config's loaders do all of the parsing and heavy lifting, thus honoring all the configs as well. It also significantly reduces the code complexity.

    There is also a plan to match Relay LSP's lookup config for either IDE (vscode, nvm, etc) settings as they provide, or by loading modules into your graphql-config!

  • #3521 aa6dbbb4 Thanks @acao! - Introduce locateCommand based on Relay LSP pathToLocateCommand:

    Now with <graphql config>.extensions.languageService.locateCommand, you can specify either the existing signature for relay, with the same callback parameters and return signature (of a string delimited by : characters), or you can return an object with {uri, range} for the exact set of coordinates for the destination range. the function can be sync or async.

    Relay LSP currently supports Type and Type.field for the 2nd argument. Ours also returns Type.field(argument) as a point of reference. It works with object types, input types, fragments, executable definitions and their fields, and should work for directive definitions as well.

    In the case of unnamed types such as fragment spreads, they return the name of the implemented type currently, but I'm curious what users prefer here. I assumed that some people may want to not be limited to only using this for SDL type definition lookups. Also look soon to see locateCommand support added for symbols, outline, and coming references and implementations.

    The module at the path you specify in relay LSP for pathToLocateCommand should work as such.

    // import it
    import { locateCommand } from './graphql/tooling/lsp/locate.js';
    export default {
      languageService: {
        locateCommand,
      },
    
      projects: {
        a: {
          schema: 'https://localhost:8000/graphql',
          documents: './a/**/*.{ts,tsx,jsx,js,graphql}',
        },
        b: {
          schema: './schema/ascode.ts',
          documents: './b/**/*.{ts,tsx,jsx,js,graphql}',
        },
      },
    };
    // or define it inline
    
    import { type LocateCommand } from 'graphql-language-service-server';
    
    // relay LSP style
    const locateCommand = (projectName: string, typePath: string) => {
      const { path, startLine, endLine } = ourLookupUtility(
        projectName,
        typePath,
      );
      return `${path}:${startLine}:${endLine}`;
    };
    
    // an example with our alternative return signature
    const locateCommand: LocateCommand = (projectName, typePath, info) => {
      // pass more info, such as GraphQLType with the ast node. info.project is also available if you need it
      const { path, range } = ourLookupUtility(
        projectName,
        typePath,
        info.type.node,
      );
      return { uri: path, range }; // range.start.line/range.end.line
    };
    
    export default {
      languageService: {
        locateCommand,
      },
      schema: 'https://localhost:8000/graphql',
      documents: './**/*.{ts,tsx,jsx,js,graphql}',
    };

    Passing a string as a module path to resolve is coming in a follow-up release. Then it can be used with .yml, .toml, .json, package.json#graphql, etc

    For now this was a quick baseline for a feature asked for in multiple channels!

    Let us know how this works, and about any other interoperability improvements between our graphql LSP and other language servers (relay, intellij, etc) used by you and colleauges in your engineering organisations. We are trying our best to keep up with the awesome innovations they have 👀!

Patch Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:

    • restores completion for object and input type fields when the document context is not detectable or parseable
    • correct top-level completions for either of the unknown, type system or executable definitions. this leads to mixed top level completions when the document is unparseable, but now you are not seemingly restricted to only executable top level definitions
    • .graphqls ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown
  • Updated dependencies [aa6dbbb4]:

[email protected]

Patch Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:

    • restores completion for object and input type fields when the document context is not detectable or parseable
    • correct top-level completions for either of the unknown, type system or executable definitions. this leads to mixed top level completions when the document is unparseable, but now you are not seemingly restricted to only executable top level definitions
    • .graphqls ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown
  • Updated dependencies [aa6dbbb4]:

[email protected]

Patch Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:

    • restores completion for object and input type fields when the document context is not detectable or parseable
    • correct top-level completions for either of the unknown, type system or executable definitions. this leads to mixed top level completions when the document is unparseable, but now you are not seemingly restricted to only executable top level definitions
    • .graphqls ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown
  • Updated dependencies [aa6dbbb4]:

[email protected]

Patch Changes

@graphiql/[email protected]

Patch Changes

@graphiql/[email protected]

Patch Changes

@graphiql/[email protected]

Patch Changes

[email protected]

Patch Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:

    • restores completion for object and input type fields when the document context is not detectable or parseable
    • correct top-level completions for either of the unknown, type system or executable definitions. this leads to mixed top level completions when the document is unparseable, but now you are not seemingly restricted to only executable top level definitions
    • .graphqls ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown

[email protected]

Patch Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:

    • restores completion for object and input type fields when the document context is not detectable or parseable
    • correct top-level completions for either of the unknown, type system or executable definitions. this leads to mixed top level completions when the document is unparseable, but now you are not seemingly restricted to only executable top level definitions
    • .graphqls ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown
  • Updated dependencies [aa6dbbb4]:

[email protected]

Minor Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fix many schema and fragment lifecycle issues, not all of them, but many related to cacheing. Note: this makes cacheSchemaForLookup enabled by default again for schema first contexts.

    This fixes multiple cacheing bugs, upon addomg some in-depth integration test coverage for the LSP server. It also solves several bugs regarding loading config types, and properly restarts the server and invalidates schema when there are config changes.

    Bugfix Summary

    • configurable polling updates for network and other code first schema configuration, set to a 30s interval by default. powered by schemaCacheTTL which can be configured in the IDE settings (vscode, nvim) or in the graphql config file. (1)
    • jump to definition in embedded files offset bug, for both fragments and code files with SDL strings
    • cache invalidation for fragments (fragment lookup/autcoomplete data is more accurate, but incomplete/invalid fragments still do not autocomplete or validate, and remember fragment options always filter/validate by the on type!)
    • schema cache invalidation for schema files - schema updates as you change the SDL files, and the generated file for code first by the schemaCacheTTL setting
    • schema definition lookups & autocomplete crossing over into the wrong project

    Notes

    1. If possible, configuring for your locally running framework or a schema registry client to handle schema updates and output to a schema.graphql or introspection.json will always provide a better experience. many graphql frameworks have this built in! Otherwise, we must use this new lazy polling approach if you provide a url schema (this includes both introspection URLs and remote file URLs, and the combination of these).

    Known Bugs Fixed

    Test Improvements

    • new, high level integration spec suite for the LSP with a matching test utility
    • more unit test coverage
    • total increased test coverage of about 25% in the LSP server codebase.
    • many "happy paths" covered for both schema and code first contexts
    • many bugs revealed (and their source)

    What's next?

    Another stage of the rewrite is already almost ready. This will fix even more bugs and improve memory usage, eliminate redundant parsing and ensure that graphql config's loaders do all of the parsing and heavy lifting, thus honoring all the configs as well. It also significantly reduces the code complexity.

    There is also a plan to match Relay LSP's lookup config for either IDE (vscode, nvm, etc) settings as they provide, or by loading modules into your graphql-config!

Patch Changes

  • #3521 aa6dbbb4 Thanks @acao! - Fixes several issues with Type System (SDL) completion across the ecosystem:

    • restores completion for object and input type fields when the document context is not detectable or parseable
    • correct top-level completions for either of the unknown, type system or executable definitions. this leads to mixed top level completions when the document is unparseable, but now you are not seemingly restricted to only executable top level definitions
    • .graphqls ad-hoc standard functionality remains, but is not required, as it is not part of the official spec, and the spec also allows mixed mode documents in theory, and this concept is required when the type is unknown
  • #3521 aa6dbbb4 Thanks @acao! - Introduce locateCommand based on Relay LSP pathToLocateCommand:

    Now with <graphql config>.extensions.languageService.locateCommand, you can specify either the existing signature for relay, with the same callback parameters and return signature (of a string delimited by : characters), or you can return an object with {uri, range} for the exact set of coordinates for the destination range. the function can be sync or async.

    Relay LSP currently supports Type and Type.field for the 2nd argument. Ours also returns Type.field(argument) as a point of reference. It works with object types, input types, fragments, executable definitions and their fields, and should work for directive definitions as well.

    In the case of unnamed types such as fragment spreads, they return the name of the implemented type currently, but I'm curious what users prefer here. I assumed that some people may want to not be limited to only using this for SDL type definition lookups. Also look soon to see locateCommand support added for symbols, outline, and coming references and implementations.

    The module at the path you specify in relay LSP for pathToLocateCommand should work as such.

    // import it
    import { locateCommand } from './graphql/tooling/lsp/locate.js';
    export default {
      languageService: {
        locateCommand,
      },
    
      projects: {
        a: {
          schema: 'https://localhost:8000/graphql',
          documents: './a/**/*.{ts,tsx,jsx,js,graphql}',
        },
        b: {
          schema: './schema/ascode.ts',
          documents: './b/**/*.{ts,tsx,jsx,js,graphql}',
        },
      },
    };
    // or define it inline
    
    import { type LocateCommand } from 'graphql-language-service-server';
    
    // relay LSP style
    const locateCommand = (projectName: string, typePath: string) => {
      const { path, startLine, endLine } = ourLookupUtility(
        projectName,
        typePath,
      );
      return `${path}:${startLine}:${endLine}`;
    };
    
    // an example with our alternative return signature
    const locateCommand: LocateCommand = (projectName, typePath, info) => {
      // pass more info, such as GraphQLType with the ast node. info.project is also available if you need it
      const { path, range } = ourLookupUtility(
        projectName,
        typePath,
        info.type.node,
      );
      return { uri: path, range }; // range.start.line/range.end.line
    };
    
    export default {
      languageService: {
        locateCommand,
      },
      schema: 'https://localhost:8000/graphql',
      documents: './**/*.{ts,tsx,jsx,js,graphql}',
    };

    Passing a string as a module path to resolve is coming in a follow-up release. Then it can be used with .yml, .toml, .json, package.json#graphql, etc

    For now this was a quick baseline for a feature asked for in multiple channels!

    Let us know how this works, and about any other interoperability improvements between our graphql LSP and other language servers (relay, intellij, etc) used by you and colleauges in your engineering organisations. We are trying our best to keep up with the awesome innovations they have 👀!

  • Updated dependencies [aa6dbbb4, aa6dbbb4, aa6dbbb4]:

Copy link
Contributor

The latest changes of this PR are not available as canary, since there are no linked changesets for this PR.

Copy link

codecov bot commented May 28, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 55.32%. Comparing base (fa0e7f7) to head (3b1d874).

Current head 3b1d874 differs from pull request most recent head 343d05a

Please upload reports for the commit 343d05a to get more accurate results.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #3603      +/-   ##
==========================================
- Coverage   60.80%   55.32%   -5.49%     
==========================================
  Files         120      115       -5     
  Lines        5616     5352     -264     
  Branches     1487     1451      -36     
==========================================
- Hits         3415     2961     -454     
- Misses       1749     1965     +216     
+ Partials      452      426      -26     

see 22 files with indirect coverage changes

@acao acao merged commit c126878 into main May 31, 2024
2 checks passed
@acao acao deleted the changeset-release/main branch May 31, 2024 19:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant