Massive optimization for multi-project users!

Warning: this changes the cache lifecycle a lot, especially after config change. Might need some fine tuning 😆 I should add lots of tests actually.

Changes

WorkspaceMessageProcessor._updateGraphQLConfig() becomes _loadAndCacheProjectConfig(projectName: string), which has grown up and become more discerning and instead of re-building all project config caches, we just load the project config it needs to handle that event, of course! What a poor design of mine before.

Because of this, the cache invalidation strategy on configuration and settings changes must change, and also allow project caches to lazily load as needed.

TODO:

• [ ] as part of this, we must get rid of this._isInitialized(), should be detected per-project. otherwise one project cache that had an error initializing (we perform parsing and load files, etc) will prevent all other projects from having a cache or language features.
• [ ] figure out what to do on MessageProcessor.handleDidChangeConfiguration - perhaps re-create the cache reset behaviour using a public method for WorkspaceMessageProcessor?
• [ ] will building the project cache lazily on editor open or save events (not workspace) make working with the language? perhaps we need to add per-project cache initialization to onChange as well. again, this fires only once per project config per server init or config file or settings change events.
• [ ] make package.json change events ignored more quickly via a quick parse-and-check for the top-level graphql namespace.
• [ ] on workspace file changes, gently update just the cache for that file (maybe seperate PR)

Jul 31 '22 08:07 acao

⚠️ No Changeset found

Latest commit: b3b5f48ef2420a131da3359ead0cf3b28165357d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Jul 31 '22 08:07 changeset-bot[bot]

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

Jul 31 '22 08:07 github-actions[bot]

actually, I think i have to get rid of this.isInitialized() entirely!

Jul 31 '22 09:07 acao

This looks great and the TODO is very clear!

Jul 31 '22 10:07 Foo-x

@Foo-x getting back to it today!

Aug 06 '22 18:08 acao

Codecov Report

Base: 65.70% // Head: 69.15% // Increases project coverage by +3.44% :tada:

Coverage data is based on head (802434f) compared to base (2d91916). Patch coverage: 23.84% of modified lines in pull request are covered.

:exclamation: Current head 802434f differs from pull request most recent head b3b5f48. Consider uploading reports for the commit b3b5f48 to get more accurate results

@@            Coverage Diff             @@
##             main    #2608      +/-   ##
==========================================
+ Coverage   65.70%   69.15%   +3.44%     
==========================================
  Files          85       72      -13     
  Lines        5106     4295     -811     
  Branches     1631     1439     -192     
==========================================
- Hits         3355     2970     -385     
+ Misses       1747     1320     -427     
- Partials        4        5       +1     

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Aug 07 '22 11:08 codecov[bot]

ok! now it's ready for review 🥳

now that we (re) initialize the project caches more selectively in this PR, i much feel better about multi-workspace support we even ensure the project is cached on workspace changes, and on change, not just on did open or save

i also feel good about the config change events. we invalidate the init status so the project caches will lazily rebuild on one of many events

Aug 07 '22 11:08 acao