Comments (6)
Hi there; I'm happy to see if there's a way to meet your needs with a new feature, but I don't think what you're looking for is $schema
.
That keyword is defined rather specifically. It defines the dialect of JSON Schema used by a schema document. It isn't defined for use in any non-schema documents, and I would be very hesitant to use it there.
I think there are other ways we can address this, but I'll need to make sure I understand your use case and think about it more.
Is your situation basically that you want to be able to embed a reference to a schema in your instances, and have each instance validate against its referenced schema?
Is it important that the schema reference comes from inside your documents, rather than some external config file or other source?
from check-jsonschema.
That keyword is defined rather specifically. It defines the dialect of JSON Schema used by a schema document. It isn't defined for use in any non-schema documents, and I would be very hesitant to use it there.
Hmm, jsonls also provides extensive autocompletion for using $schema values. (json.schemastore.org). Vscode respects the schema set also. See https://code.visualstudio.com/docs/languages/json#_mapping-in-the-json for the docs. It confirms that specifying it this way is non-standard, but it seems like an established procedure.
Is it important that the schema reference comes from inside your documents, rather than some external config file or other source?
Yeah, a project might have json files for different schemas. Having such info inside the documents will ensure that IDEs provide proper autocompletion without having to manually configure them. Same for the actual linting, where one would otherwise need a mapper-like config file. But those are not standardized in different text editors/IDEs AFAIK.
from check-jsonschema.
I asked around a little to see if the spec maintainers have strong feelings about this usage.
The answer is that it's not part of the spec, as noted by VSCode, but that there's no longer much interest in actively discouraging this usage and that tools should feel free to implement it where it makes sense.
My plan is therefore to add a flag for this. Exact name TBD, but my first thought is --schema-from-instances
.
Input on the naming is very much welcome, since that's pretty long.
I'll need to take some time to work out behavior for this. There are some details to work out -- e.g. if given multiple files, do you load all of their relevant schemas first, or do you process them one-at-a-time? -- but I'm sure everything is solvable.
Consider the feature request accepted; but I don't have a clear idea of when I'll get around to it.
from check-jsonschema.
Exact name TBD, but my first thought is --schema-from-instances. Input on the naming is very much welcome, since that's pretty long.
How would that flag work in case I run it on files where only some of them have $schema set? And would that flag discard the schemafile that might be provided as another option? (not allowing both to be set could be valid too)
Consider the feature request accepted; but I don't have a clear idea of when I'll get around to it.
Amazing! Thanks a lot :)
from check-jsonschema.
How would that flag work in case I run it on files where only some of them have $schema set?
I presume it should fail on those files. The interface would be something like
check-jsonschema --schema-from-instances foo.json bar.json
During such usage -- where everything is fully explicit -- if bar.json
doesn't have $schema
and foo.json
does, I can't see a strong argument for anything other than treating it as an error.
Realistic usage may look more like
check-jsonschema --schema-from-instances myfiles/**/*.json
But that doesn't move the needle significantly. First because that's "just" a shorthand which expands to some explicit argument list. But second, what if the caller meant to specify only files with $schema
, but one of them accidentally had it unset? Again, better to error.
And would that flag discard the schemafile that might be provided as another option? (not allowing both to be set could be valid too)
The two would be mutually exclusive, like the other schema selection options which exist today. (--check-metaschema
and --builtin-schema
)
If I had designed check-jsonschema
to have subcommands when I first created it, this would probably be a dedicated subcommand, as would each of the other schema selection modes. Unfortunately, it's a tricky change to make in a backwards compatible way with the current implementation, so I haven't put any significant time against reworking that yet.
from check-jsonschema.
I presume it should fail on those files.
What if you'd like to scan all .json
(and .yaml
/.toml
) files in the repo for available $schema
, but check specific schema only those that have $schema
?
from check-jsonschema.
Related Issues (20)
- Allow validating YAML with inline yaml-language-server comments HOT 2
- Allow optionally interpreting .json files as JSON5 HOT 4
- Failure resolving ref to anchor within same schema after v0.24.0 HOT 5
- Support new GitHub Actions Runner Scale Sets HOT 2
- Opening concurrent file handles for all instancefiles risks breaching OS limit. HOT 6
- Support ECMAScript unicode-mode RegExp usage for 'pattern' and 'patternProperties' HOT 3
- [BUG] `github-workflows-require-timeout.json`: `timeout-minutes` should allow expressions HOT 4
- Feature request: add line numbers to the output HOT 3
- Update vendored bitbucket schema HOT 1
- Feature request: add file names to the ouptut even if validation is OK HOT 3
- "unexpected keyword argument 'registry'" when validating specific GitHub workflow HOT 4
- Bug: Globs work in my machine but fails on CI HOT 3
- AttributeError not parsing schema correctly. HOT 2
- Cannot validate date-time via the CLI tool HOT 4
- Distribute the check-jsonschema tool in a manner which does not assume a Python environment
- Validation passes for misspelled optional child properties in Google Cloud Build schema HOT 7
- check-gitlab-ci: coverage is not a regex HOT 9
- Check yaml with check-metaschema option HOT 3
- Non-JSON files ignored despite --default-type being set HOT 4
- check-azure-pipelines: doesn't handle default value for boolean parameter properly HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from check-jsonschema.