- JSON becomes a true plugin instead of a bundled module.
- New plugin's ID is intentionally set equal to the old module name so that external dependent plugins would not face difficulties migrating to the new layout.
- All discovered internal plugins that implicitly depended on the JSON module currently unconditionally depend on the plugin.
- Consider extracting optional modules in a subset of affected plugins: spring.boot, intellij.yaml, intellij.java
- Consider testing the following IDEs that bundle JSON extension using xml:include: writerside, rider
- Refactor PlatformLangXmlPlugin to avoid api breakages
GitOrigin-RevId: 7d92b0c5905154c4f6f25d55f3246e79da79e278
Unspecified type in the meta schema lead to treating many of the instance fields as either an object, or a boolean (as it is specified in the #meta schema node).
GitOrigin-RevId: 4c1441f161039eef502fd7e3e4b64295d04cffc3
this is needed to handle cases when the value is "expandable" - there are two different options to write the same (product = lib or product {type = lib}), but in some cases one of them requires expanding by default (lib requires a set of platforms)
instead of introducing the notion of "expandable" into the schema, we just provide an ability to provide a custom completion insert handler to handle tricky cases like that
GitOrigin-RevId: 5e54f19326891d7d02061b338efb392fc0ae2634
- Use virtual file as a key in schema storage map
- Prefer KFMap instead of lazy properties
- Fix various minor code-style problems
GitOrigin-RevId: 20825456c5b98f654e3957eb9783badb21a6d433
Current commit disables the new JsonSchemaObject implementation to record test results before the recent susystem changes. After the statistics is collected, new implementation should be turned on again for further comparison
GitOrigin-RevId: f9cc59d2f4df2f47c6f62bf77cf3ff2efbe073fe
The key is used across the json plugin codebase in the hottest in terms of memory allocations places. The goal is to create such a schema object implementation, that would be capable of providing schema data the same way that the existing API does, but to save up on memory allocations and GC.
GitOrigin-RevId: e763ff89ec81628dd58708d6b18118939fc8b4c7
Primarily used by the Amper yaml files, this functionality provided great value but using incorrect approach at the same time. Previously stored inside a JsonSchemaObject, instances of NestedCompletionsRoot are now provided during json schema-based completion via the corresponding extension point. Caching of nested completion roots is now a responsibility of implementors. SchemaObject instances are no more mutated by this API, extension interface itself is simplified too and does not depend on a particular schema object instance - instead it assumes that the provided completions tree is always constructed for the very inspected file root
GitOrigin-RevId: e8ab13ab6af569f50525f37a1291d670595a7fe6
It inserts all known properties from the corresponding JSON-schema into the JsonObject a caret is located in.
GitOrigin-RevId: a48ef273a059283d6fa34ad25f7c06f30e77798c
Might be useful in cases where json schema is an implementation detail: user should only work with features provided by json schema mechanism (like validation and completion), but not with the schema file itself
GitOrigin-RevId: 66284d55d9e5afb2dc0b3468ba66ec8015f18441
