-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce a JSON schema for composer.json #736
base: master
Are you sure you want to change the base?
Conversation
This seems like a good idea, John. Would the next step of this be to define each module's schema in the individual modules or add them all into this one? |
Yeah, the difficulty of this is the decentralised nature of the configuration; we'd need to pull them together somehow without centralising it somewhere. Alternatively, we could bodge it into a central config, but I'd really prefer not to. Definitely something we should look at implementing though imo |
Yeah we can do this by putting a schema.json into each module which contains its module definition, and then the main schema.json in I'll put aside a couple of hours next week to carry on with the proof of concept. |
Right, but that then centralises a dependency in |
I think centralising the list of modules for this purpose is reasonable and manageable. As far as I know we don't have a high turnover of new or removed modules. The alternative would be to come up with a build step that combines the schemas from all the modules, but I'm not too keen on that, and presumably that would also require centralising a list of the modules to combine. The schemas for the modules themselves would live within each module so maintaining the module schemas would remain the responsibility of each module.
Yeah I used |
That is true, but it also breaks the conceptual modularity by having dependencies between the modules, so we want to avoid it as much as possible. Additionally, we support both custom modules and a mixed list of modules depending on which plan a user is on; the latter is a minimal problem for something like this was the worst case is you get too many suggestions, but still avoidable I think.
This can be decentralised using the same mechanism we use for installation path overrides, where modules could specify a That's definitely my preferred option, provided the schema will work correctly with a local file rather than a full URL, which it seems is perfectly fine. |
As a start, could we atleast define the |
It's possible to use
allOf
in JSON Schema to combine the constraints from multiple schemas into one. This means we can create a schema for composer.json which is a combination of the official Composer schema with our own schema for theextra.altis
properties.Adding
"$schema": "vendor/altis/core/schema.json",
to the top of an application-level composer.json file means VS Code provides all the JSON schema goodness you'd expect for a complete schema, including autocomplete, hover documentation with links, and validation, both for the Composer properties and for the custom Altis properties withinextra.altis
.By using a root
definitions
we also allow all the module definitions to appear inextra.altis.modules
as well as each environment withinextra.altis.environments[...]
without duplicating everything five times.Related: #28
Screenshots
Top level modules:
Environment modules:
Module property:
Autocomplete
Status
This is a proof of concept. There is a maintenance overhead for such a schema so we could make more use of
$ref
in order to pull in each module definition from its place in the vendor directory if that's preferable.Thoughts?