Define defaultSnippets for JSONSchema additionalProperties - visual-studio-code

As the title suggests, I would like to define a vscode defaultSnippet for the additionalProperites of a JSONObject. The JSONSchema looks like the following
"$schema ": "http://json-schema.org/draft-07/schema#",
"type":"object",
"additionalProperties":{
"type": "object",
"properties":{
"name":{"type":"string"}
}
}
So just adding defaultSnippet property does not seem to work:
"$schema ": "http://json-schema.org/draft-07/schema#",
"type":"object",
"additionalProperties":{
"defaultSnippets": [{
"label": "test",
"description": "Additional property template",
"body": {
"$1": {
"name": "$2"
}
}
}],
"type": "object",
"properties":{
"name":{"type":"string"}
}
}
Is there a workaround to obtain the same behavior?

Your code is correct, but vscode at this moment is only checking properties for snippets. I had the same problem, so I've created Pull Request with fix for this issue.
https://github.com/microsoft/vscode-json-languageservice/pull/62
You can replace default extension if you in rush or just wait for merge and update.

Related

How to add configurations to user to a VSCode extension

I am trying to add a simple configuration to my VSCode extension, but I can't find the correct information.
I just want that the user have a string input field, that has a default value, and read it from my typescript code through the vscode library
Can someone provide me and example about which file should I add, where, and how to consume? also if more configurations are needed.
Thanks!
Ok, found
I need to add into my package.json
...
"contributes": {
"commands": [
...
],
"configuration": {
"title": "My Extension",
"properties": {
"myExtension.myProperty": {
"type": "string",
"default": "default",
"description": "description"
}
}
}
},
and consume
vscode.workspace.getConfiguration('myExtension').myProperty;

How do I use an extended definition and not allow additional properties in a way that is compatible with multiple validators (JSON schema draft 7)?

I am creating a strict validator for a complex JSON file and want to re-use various definitions in order to keep the schema manageable and easier to update.
According to the documentation it is necessary to use allOf to extend a definition to add more properties. This is exactly what I've done, but I find that without use of additionalProperties set to false validation doesn't prevent arbitrary other properties being added.
The following massively cut-down schema demonstrates what I'm doing:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://example.com/schema/2021/02/example.json",
"description": "This schema demonstrates how VSCode's JSON schema mechanism fails with allOf used to extend a definition",
"definitions": {
"valueProvider": {
"type": "object",
"properties": {
"example": {
"type": "string"
},
"alternative": {
"type": "string"
}
},
"oneOf": [
{
"required": [
"example"
]
},
{
"required": [
"alternative"
]
}
]
},
"selector": {
"type": "object",
"allOf": [
{
"$ref": "#/definitions/valueProvider"
},
{
"required": [
"operator",
"value"
],
"properties": {
"operator": {
"type": "string",
"enum": [
"IsNull",
"Equals",
"NotEquals",
"Greater",
"GreaterOrEquals",
"Less",
"LessOrEquals"
]
},
"value": {
"type": "string"
}
}
}
],
"additionalProperties": false
}
},
"properties": {
"show": {
"properties": {
"name": {
"type": "string"
},
"selector": {
"description": "This property does not function correctly in VSCode",
"allOf": [
{
"$ref": "#/definitions/selector"
},
{
"additionalProperties": false
}
]
}
},
"additionalProperties": false
}
}
}
This works a treat in IntelliJ IDEA's JSON editor (2020.3.2 ultimate edition) when editing JSON against this schema (using a schema mapping). For example, the file ex-fail.json's content of:
{
"show": {
"name": "a",
"selector": {
"example": "a",
"operator": "IsNull",
"value": "false",
"d": "a"
}
}
}
Is correctly validated, simply highlighting "d" as not allowed, thus:
However, when I use the very same schema and JSON file with VSCode (1.53.2) with vanilla configuration (except for a schema mapping) VSCode erroneously marks "example", "operator", "value" and "d" as not allowed. It looks like this in the VSCode editor:
If I remove the additionalProperties definition from the show.selector property, both IDEA and VSCode indicate that all is well, including allowing the "d" property - in doing this I can simplify that property definition to:
"selector": {
"description": "This property does not function correctly in VSCode",
"$ref": "#/definitions/selector"
}
What can I do to the schema to support both IDEA and VSCode whilst disallowing additional properties where they should not appear?
PS: The schema mapping in VSCode is simply along the lines of:
{
"json.schemas": [
{
"fileMatch": [
"*/config/ex-*.json"
],
"url": "file:///C:/my/path/to/example-schema.json"
}
]
}
You cannot do what you ask with JSON Schema draft-07 or prior.
The reason is, when $ref is used in a schema object, all other properties MUST be ignored.
An object schema with a "$ref" property MUST be interpreted as a
"$ref" reference. The value of the "$ref" property MUST be a URI
Reference. Resolved against the current URI base, it identifies the
URI of a schema to use. All other properties in a "$ref" object MUST
be ignored.
https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-01#section-8.3
We changed this to not be the case for draft 2019-09.
It sounds like VSCode is merging the properties in applicators upwards to the nearest schema object (which is wrong), and IntelliJ IDEA is doing something similar but in a different way (which is also wrong).
The correct validation result for your schema and instance is VALID. See the live demo here: https://jsonschema.dev/s/C6ent
additionalProperties relies on the values of properties and patternProperties within the SAME schema object. It cannot "see through" applicators such as $ref and allOf.
For draft 2019-09, we added unevaluatedProperties, which CAN "see through" applicator keywords (although it's a little more complex than that).
Update:
After reviewing your update, sadly the same is still true.
One approach makes it sort of possible but involves some duplication, and only works when you control the schemas you are referencing.
You would need to redefine your selector property like this...
"selector": {
"description": "This property did not function correctly in VSCode",
"allOf": [
{
"$ref": "#/definitions/selector"
},
{
"properties": {
"operator": true,
"value": true,
"example": true,
"alternative": true
},
"additionalProperties": false
}
]
}
The values of a property object are schema values, and booleans are valid schemas. You don't need (or want to) deal with their validation here, only say these are the allowed ones, followed by no additionalProperties.
You'll also need to remove the additionalProperties: false from your definition of selector, as that is preventing ALL properties (which I now guess is why you saw that issue in one of the editors).
It involves some duplication, but is the only way I'm aware of that you can do this for draft-07 or previous. As I said, not a problem for draft 2019-09 or above due to new kewords.
additionalProperties is problematic because it depends on the properties and patternProperties. The result is that "additionalProperties": false effectively blocks schema composition. #Relequestual showed one alternative approach, here is another approach that is a little less verbose, but still requires duplication of property names.
draft-06 and up
{
"allOf": [{ "$ref": "#/definitions/base" }],
"properties": {
"bar": { "type": "number" }
},
"propertyNames": { "enum": ["foo", "bar"] },
"definitions": {
"base": {
"properties": {
"foo": { "type": "string" }
}
}
}
}

AWS CloudFormation Parameter values specified for a template which does not require them

I porting code from ruby to Python for CloudFormation stack creation projects. Below is a stack that I just keep getting 'Parameter values specified for a template which does not require them.'
This really doesn't tell me anything.
I have checked the json against the schemas and all was ok, and checked against the stack created by the original code and it matches, so can someone see an issue here, or at least point me in the right direction.
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "EcsStack-5ad0c44afbf508d0b5a158df0da307fca33f5f63",
"Outputs": {
"marc1EcsCluster": {
"Value": {
"Ref": "marc1EcsCluster"
}
},
"marc1EcsClusterArn": {
"Value": {
"Fn::GetAtt": [
"marc1EcsCluster",
"Arn"
]
}
}
},
"Parameter": {
"Vpc": {
"Description": "VPC ID",
"Type": "String"
}
},
"Resources": {
"CloudFormationDummyResource": {
"Metadata": {
"Comment": "Resource to update stack even if there are no changes",
"GitCommitHash": "5ad0c44afbf508d0b5a158df0da307fca33f5f63"
},
"Type": "AWS::CloudFormation::WaitConditionHandle"
},
"marc1EcsCluster": {
"Type": "AWS::ECS::Cluster"
}
},
"Transform": "AWS::Serverless-2016-10-31"
}
As more general advice, the CloudFormation Linter will catch these errors with messages like:
E1001: Top level item Parameter isn't valid
template.json:19

Getting expected object definitions from Magento 2 REST API

When calling the Magento 2 REST API to get the schema for working with products using:
..rest/all/schema?services=catalogProductRepositoryV1
The response back includes:
...
"paths": {
"/V1/products": {
"post": {
"tags": [
"catalogProductRepositoryV1"
],
"description": "Create product",
"operationId": "catalogProductRepositoryV1SavePost",
"parameters": [
{
"name": "$body",
"in": "body",
"schema": {
"required": [
"product"
],
"properties": {
"product": {
"$ref": "#/definitions/catalog-data-product-interface"
},
"saveOptions": {
"type": "boolean"
}
},
"type": "object"
}
}
],...
How do you go about getting the definition/schema for the "product" object that it expects during a POST call? i.e. the following definition:
"properties": {
"product": {
"$ref": "#/definitions/catalog-data-product-interface"
},
Looks like its only possible using the swagger GUI. Essentially replicate these steps and change your search term for whatever you're searching for:
Go to: http://devdocs.magento.com/swagger/index.html
Ctrl + f >> search for whatever you're after. In the case of the above: catalogProductRepositoryV1
Expand the API interface by clicking it
Choose your REST Method
Under "Parameters" there will be a Model/Model Schema showing you what payload it expects.
Welcome to Swagger! It's great when you know how to use it!

Multiselect in Impresspages Plugin Options

How may I use a multiselect field in the Impresspages Plugin options. Something like this:
{
"label": "Social Nets",
"name": "socialNets",
"type": "select",
"multiple": "multiple",
"default": "",
"values": ["", "facebook", "twitter", "pintrest"]
}
Of course, the field above "multiple" doesn't work in this code snip. So, how to implement it in the plugin options json file?
You can use "Checkboxes" field type
"options": [
{
"label": "XXX",
"name": "xxx",
"type": "Checkboxes",
"values": ["option1", "option2", "options3", "option4"]
}
]
There is no such option implemented in the core of the system. Meaning, there's no such field type as 'multiselect'. You can check how other fields are implemented and extend the core, create pull-request and we'll add it in next release.