Skip to content

Latest commit

 

History

History
895 lines (525 loc) · 48.1 KB

CHANGELOG.md

File metadata and controls

895 lines (525 loc) · 48.1 KB

Change Log

0.13.2

Patch Changes

0.13.0

Minor Changes

0.12.1

Patch Changes

  • #3773 31edfab Thanks @yaacovCR! - use latest stable version of graphql 16.9.0 for bundled libraries & tests

0.12.0

Minor Changes

Patch Changes

0.11.3

Patch Changes

0.11.2

Patch Changes

  • #3647 ba5720b Thanks @acao! - several LSP fixes and improvements:

    Bugfixes

    debounce schema change events to fix codegen bugs to fix #3622

    on mass file changes, network schema is overfetching because the schema cache is now invalidated on every watched schema file change

    to address this, we debounce the new onSchemaChange event by 400ms

    note that schemaCacheTTL can only be set in extension settings or graphql config at the top level - it will be ignored if configured per-project in the graphql config

    Code Improvements

    • Fixes flaky tests, and schemaCacheTTL setting not being passed to the cache
    • Adds a test to validate network schema changes are reflected in the cache

  • Updated dependencies [ba5720b, fdec377, e2c04c7]:

0.11.1

Patch Changes

0.11.0

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

    • #3318
    • #2357
    • #3469
    • #2422
    • #2820
    • many more!

    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]:

0.9.3

Patch Changes

  • #3549 e5efc97e Thanks @acao! - Fix OpenVSX build by re-using the vsce build (astro compiler bug)

0.9.2

Patch Changes

  • #3543 defc126b Thanks @acao! - Temporarily revert a syntax highlighting bugfix that caused more bugs

0.9.1

Patch Changes

0.9.0

Minor Changes

Patch Changes

  • #3514 36c7f25c Thanks @acao! - fix svelte parsing, re-load config only on config changes

    • fix esbuild bundling of typescript for svelte2tsx!
    • confirm with manual testing of the vsix extension bundle ✅
    • ensure that the server only attemps to parse opened/saved files when the server is activated or the file is a config file

  • Updated dependencies [98af5307, 36c7f25c]:

0.8.25

Patch Changes

  • #3503 6c7adf85 Thanks @acao! - Temporarily revert svelte parsing until we can fix bundling issues with svelte2tsx. For now we return to using the vue parser to parse svelte files which will invariably cause some issues, such as being off by several characters

  • Updated dependencies [6c7adf85]:

0.8.24

Patch Changes

0.8.23

Patch Changes

0.8.22

Patch Changes

  • #3490 334224b4 Thanks @acao! - - add ruby syntax support

    • add graphql syntax support in markdown codeblocks for js, ts, jsx, tsx, svelte, vue, ruby, rescript, reason, ocaml, php and python
    • make textmate injectors more performant and specific, eliminate redundant config

    Big thanks to @RedCMD and @aeschli for your help!

  • #3488 d5028be2 Thanks @acao! - Bump graphql & graphql-tools version to fix potential runtime security bugs

  • 22771f35 Thanks @acao! - Fixes to svelte parsing, tag parsing refactor

  • Updated dependencies [d5028be2, 22771f35]:

0.8.21

Patch Changes

0.8.20

Patch Changes

0.8.19

Patch Changes

0.8.18

Patch Changes

0.8.17

Patch Changes

0.8.16

Patch Changes

0.8.15

Patch Changes

0.8.14

Patch Changes

0.8.14-alpha.0

Patch Changes

0.8.13

Patch Changes

0.8.12

Patch Changes

0.8.11

Patch Changes

0.8.10

Patch Changes

0.8.9

Patch Changes

0.8.8

Patch Changes

0.8.7

Patch Changes

0.8.6

Patch Changes

0.8.5

Patch Changes

0.8.4

Patch Changes

0.8.3

Patch Changes

0.8.2

Patch Changes

  • #2488 967006a6 Thanks @acao! - DisablefillLeafsOnComplete by default

    Users found this generally annoying by default, especially when there are required arguments

    Without automatically prompting autocompletion of required arguments as well as lead expansion, it makes the extension harder to use

    You can now supply this in your graphql config:

    config.extensions.languageService.fillLeafsOnComplete

    Setting it to to true will enable this feature. Will soon add the ability to manually enable this in monaco-graphql as well.

    For both, this kind of behavior would be better as a keyboard command, context menu item &/or codelens prompt

0.8.1

Patch Changes

  • #2829 c835ca87 Thanks @acao! - major bugfixes with onDidChange and onDidChangeWatchedFiles events

0.8.0

Minor Changes

  • #2827 b422003c Thanks @acao! - Introducing vue.js support for intellisense! Thanks @AumyF

Patch Changes

0.7.13

Patch Changes

0.7.12

Patch Changes

0.7.11

Patch Changes

0.7.10

Patch Changes

0.7.9

Patch Changes

0.7.8

Patch Changes

  • #2616 b0d7f06c Thanks @acao! - support vscode multi-root workspaces! creates an LSP server instance for each workspace.

    WARNING: large-scale vscode workspaces usage, and this in tandem with graphql.config.* multi-project configs could lead to excessive system resource usage. Optimizations coming soon.

  • Updated dependencies [b0d7f06c]:

0.7.7

Patch Changes

0.7.6

Patch Changes

  • #2665 324fbedb Thanks @acao! - Port the inline query execution capability from the original vscode-graphql repository as promised. More improvements to come!

0.7.5

Patch Changes

  • #2759 67b1e5e9 Thanks @acao! - Fixes #2671 bug for SDL schema support and .graphql files! pin vscode-languageclient to 8.0.2 version. Thanks @MariaSolOs for the fix!

0.7.4

Patch Changes

0.7.3

Patch Changes

0.7.2

Patch Changes

  • #2660 34d31fbc Thanks @acao! - bump ts-node to 10.x, so that TypeScript based configs (i.e. .graphqlrc.ts) will continue to work. It also bumps to the latest patch releases of graphql-config fixed several issues with TypeScript loading (v4.3.2, v4.3.3). We tested manually, but please open a bug if you encounter any with schema-as-url configs & schema introspection.

  • Updated dependencies [34d31fbc]:

0.7.1

Patch Changes

0.7.0

Minor Changes

  • #2573 a358ac1d Thanks @acao! - ## Enhancement

    Here we move vscode grammars and basic language support to a new GraphQL.vscode-graphql-syntax extension. GraphQL.vscode-graphql now depends on this new syntax extension. This constitutes no breaking change for vscode-graphql users, as this extension will be installed automatically as an extensionDependency for vscode-graphql. Both extensions will now have independent release lifecycles, but vscode will keep them both up to date for you :)

    Firstly, this allows users to only install the syntax highlighting extension if they don't need LSP server features.

    Secondly, this subtle but important change allows alternative LSP servers and non-LSP graphql extensions to use (and contribute!) to our shared, graphql community syntax highlighting. In some ways, it acts as a shared tooling & annotation spec, though it is intended just for vscode, it perhaps can be used as a point of reference for others implementing (embedded) graphql syntax highlighting elsewhere!

    If your language and/or library and/or framework would like vscode highlighting, come join the party!

    If you use relay, we would highly reccomend using the relay-compiler lsp extension for vscode Relay Graphql (meta.relay). They will be using the new standalone syntax extension very soon!

    Even non-relay users may want to try this extension as an alternative to our reference implementation, as relay's configuration has relative similarity with graphql-config's format, and doesn't necessitate the use of relay client afaik. We are working hard to optimize and improve graphql-language-service-server as a typescript reference implementation, and have some exciting features coming soon, however it's hard to offer more than a brand new & highly performant graphql LSP server written in Rust based on the latest graphql spec with a (mostly) paid team and dedicated open source ecosystem community of co-maintainers! And their implementation appears to allow you to opt out of any relay-specific conventions if you need more flexibility.

0.6.0

Minor Changes

0.5.0

Minor Changes

  • #2557 3304606d Thanks @acao! - upgrades the vscode-languageserver and vscode-jsonrpc reference implementations for the lsp server to the latest. also upgrades vscode-languageclient in vscode-graphql to the latest 8.0.1. seems to work fine for IPC in vscode-graphql at least!

    hopefully this solves #2230 once and for all!

Patch Changes

0.4.15

Patch Changes

0.4.14

Patch Changes

  • #2519 de5d5a07 Thanks @acao! - enable graphql-config legacy mode by default in the LSP server

0.4.13

Patch Changes

0.4.12

Patch Changes

0.4.11

Patch Changes

0.4.10

Patch Changes

  • #2474 70bc61ee Thanks @acao! - Fix bug with typed parameters on the gql/graphql/etc tagged templates!

0.4.8

Patch Changes

  • #2470 d0017a93 Thanks @acao! - Aims to resolve #2421

    • graphql config errors only log to output channel, no longer crash the LSP
    • more performant LSP request no-ops for failing/missing config

    this used to fail silently in the output channel, but vscode introduced a new retry and notification for this

    would like to provide more helpful graphql config DX in the future but this should be better for now

  • Updated dependencies [d0017a93]:

0.4.7

Patch Changes

0.4.6

Patch Changes

  • #2395 f7f1e900 Thanks @acao! - Release vscode-graphql changes since publishing was broken

0.4.5

Patch Changes

  • #2382 1bea864d Thanks @acao! - allow disabling query/SDL validation with graphql-config setting { extensions: { languageService: { enableValidation: false } } }.

    Currently, users receive duplicate validation messages when using our LSP alongside existing validation tools like graphql-eslint, and this allows them to disable the LSP feature in that case.

  • Updated dependencies [6db28447, 1bea864d]:

0.4.4

Patch Changes

0.4.3

Patch Changes

0.4.2

Patch Changes

  • c36504a8 Thanks @acao! - - upgrade graphql-config to latest in server
    • remove graphql-config dependency from vscode-graphql and graphql-language-service
    • fix vscode-graphql esbuild bundling bug in vscode-graphql #2269 by fixing esbuild version
  • Updated dependencies [c36504a8]:

0.4.0

Minor Changes

  • #2276 6973a20b Thanks @acao! - Simplified, merged with monorepo, dropped operation execution feature, we will recommend an alternative instead.

Patch Changes

0.3.52

Patch Changes

  • #452 8878e42 Thanks @acao! - Limit activation events for package.json file provided graphql-config

0.3.50

Patch Changes

  • #448 f894dad Thanks @acao! - upgrade graphql-language-service-server to the latest patch version for windows path fix
  • #436 2370607 Thanks @orta! - Adds support for making clicking on the graphql status item show the output channel
  • #422 0e2235d Thanks @orta! - Use the vscode theme API to set the right colours for the status bar item

0.3.48

Patch Changes

0.3.43

Patch Changes

  • #391 6be5593 Thanks @acao! - LSP upgrades:

    • bugfix for insertText & completion on invalid list types
    • add support for template strings and tags with replacement expressions, so strings like these should work now:
    const myQuery =
  /* GraphQL */
  `
        ${myFragments}
        query MyQuery {
            something
            ${anotherString}
        }
    `;
    const myQuery = gql`
        ${myFragments}
        query MyQuery {
            something
            ${anotherString}
        }
    `;

All notable changes to the "vscode-graphql" extension will be manually documented in this file.

Check Keep a Changelog for recommendations on how to structure this file.

The git log should show a fairly clean view of each of these new versions, and the issues/PRs associated.

0.3.25

Remove node_modules from bundle after adding esbuild to make the extension bundle smaller

0.3.24

Add highlighting and language support for .mjs, .cjs, .es6, .esm and other similar extensions

0.3.23

Major bugfixes for language features. Most bugs with language features not working should be resolved.

The useSchemaFileDefinition setting was deprecated, and SDL-driven projects work by default. If you want to opt-into an experimental feature to cache graphql-config schema result for definitions (useful for remote schemas), consult the readme on how to configure cacheSchemaFileForLookup option in vscode settings, or graphql config (yes you can enable/disable it per-project!)

Definition lookup works by default with SDL file schemas. cacheSchemaFileForLookup must be enabled if you have a remote schema want definition lookup for input types, etc in queries

0.3.19

  • support graphql-config for .ts and .toml files by upgrading graphql-config & graphql-language-service-server
  • use * activation event, because graphql-config in package.json is impossible to detect otherwise using vscode activationEvents
  • support additional language features in graphql-language-service-server such as interface implements interfaces, etc
  • upgrade operation execution to use a new graphql client and support subscriptions
  • fix openvsx & vscode publish by re-creating PATs and signing new agreements

Note: there are still some known bugs in the language server we will be fixing soon:

  • if you don't see editor output, please check your config
  • output channel may show errors even after your configuration works
  • there may be issues with schema file loading

0.3.13

LSP bugfixes:

0.3.8

  • require dotenv in the server runtime (for loading graphql config values), and allow a graphql-config.dotEnvPath configuration to specify specific paths
  • reload server on workspace configuration changes
  • reload sever-side graphql-config and language service on config file changes. definitions cache/etc will be rebuilt
    • note: client not configured to reload on graphql config changes yet (i.e endpoints)
  • accept all graphql-config.loadConfig() options

0.3.7

  • update underlying graphql-language-service-server to allow .gql, .graphqls extensions

0.3.6

  • documentation fix

0.3.5

  • readme documentation improvements, more examples, FAQ, known issues
  • bump graphql-language-service-server to allow implicit fragment completion (non-inline fragments). just include your fragments file or string in the graphql-config documents

0.3.4

  • remove insiders announcement until tooling is properly in place, and insiders extension is up to date

0.3.3

  • useSchemaFileDefinition setting

0.3.2

  • #213: bugfix for input validation on operation execution

0.3.1 🎉

  • upgrade to graphql-config@3
  • upgrade to latest major version of graphql-language-service-server
    • upgrades graphql-config@3
    • remove watchman dependency 🎉
    • introduce workspace symbol lookup, outline
    • validation and completion for input variables
    • generate a schema output by default, for code-first schemas. SDL first schemas have an override option now

Historical 0.2.x versions

[todo]