You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Create a schema for auto-completion of ffigen.yaml #468
We could rely on the YAML extension and schemastore (not sure about support in other IDEs/editors), but we could also add the schemas to Flutter and Dart extensions + automatically generate the new schemas.
An advantage of having the schema validation as a part of Flutter/Dart extensions is the fact that we can load the correct version based on the project's Flutter/Dart version.
cc @jonasfj from the pub side of things. I think supporting schema/auto completion is a "nice to have". How hard is it to maintain it though?
cc @dcharkes
but we could also add the schemas to Flutter and Dart extensions + automatically generate the new schemas.
I'm not sure if I understand the suggestion here. Do you mean for the Dart extension to parse the schema and validate the YAML file? That feels out-of-scope for the Dart extension itself, but perhaps some validation/code completion could/should be done by the Dart analysis server?
It's the Dart analysis server that provides validation and code completion inside pubspec.yaml and analysis_options.yaml. It doesn't currently do it via a schema but has its own code for this (some of the things it does could not be represented in a schema) but it also knows what version of the SDK is being used (I'm not familiar with ffigen, but presume it's an SDK tool and therefore versions with the SDK?).
but we could also add the schemas to Flutter and Dart extensions + automatically generate the new schemas.
I'm not sure if I understand the suggestion here. Do you mean for the Dart extension to parse the schema and validate the YAML file? That feels out-of-scope for the Dart extension itself, but perhaps some validation/code completion could/should be done by the Dart analysis server?
It's the Dart analysis server that provides validation and code completion inside pubspec.yaml and analysis_options.yaml. It doesn't currently do it via a schema but has its own code for this (some of the things it does could not be represented in a schema) but it also knows what version of the SDK is being used (I'm not familiar with ffigen, but presume it's an SDK tool and therefore versions with the SDK?).
Oh, OK. I had the YAML extension installed so didn't realize that Dart analysis server already provides validation and code completion for pubspec.yaml and analysis_options.yaml and assumed the YAML extension is using the available schema.
ffigen is maintained by us so we could technically add the parser/validator/completer to analysis server. However, I don't think we need much more than a simple JSON Schema so maybe that's an overkill!
However, I don't think we need much more than a simple JSON Schema so maybe that's an overkill!
If we want to provide this and not rely on a third-party extension, it might be the simplest way. Adding it to the Dart extension outside of the server would likely be more involved (and generally we try to keep things in the language server where they can be used by all editors and not just VS Code).
... we could technically add the parser/validator/completer to analysis server. However, I don't think we need much more than a simple JSON Schema so maybe that's an overkill!
I'd be fine having this support in the analysis server, and I believe that's where it belongs.
The biggest difference is that we have the ability to add some non-generic logic when doing so makes sense in order to provide a slightly better experience.
We can also sometimes do a more complete job of validation than can be done using only a schema because we can check for constraints that can't be expressed in a schema.
Whether it's overkill depends, at least in part, on how often users edit ffigen.yaml and how difficult it is for them to get it right.
Whether it's overkill depends, at least in part, on how often users edit ffigen.yaml and how difficult it is for them to get it right.
It sounds slightly overkill to me.
Though, if someone wants to volunteer for giving our users top-notch user experience, I'm not opposed to it. As long as we generate the implementation from the config spec in FFIgen so that maintenance burden is minimal.
The support we have code code completion is essentially equivalent to a schema, though it's closer to a procedural implementation than a declarative one.
I checked the link and it's quite nice and simple to implement. I wouldn't assume generating a "producer" is harder than the JSON schema.
"Producer" seem to only be useful for completion purposes, it still won't "validate" the data type like JSON schema. But, I think that completion is a much nicer feature than validation – at least for ffigen and jnigen.
Schemas are not versioned based on the version of ffigen that you're using.
We would need to ask users to rely on a third-party extension and either make PRs to schemastore or ask users to add a url to where we serve the schemas. Realistically, this reduces the number of people who actually end up using the feature.
Doesn't everyone have a ton of editors installed in VSCode anyway?
No, we don't. :)
(I have absolutely no confidence that all officially available plugins have been properly security-vetted, before being let loose on my potentially proprietary code. Doesn't mean I don't add extensions, I just try to reduce the attack area by not installing too many.)
About versioning, you should add a version field to the ffigen.yaml format.
Then you should be able to use JSON schema conditionals to have specific schemes for each version.
Say:
(As someone who already experienced the XML craze, with XML schemas everywhere, that which JSON was the non-bloated response to, I guess we're getting closer to the next revolution. 😉)
I would suggest avoiding a version number on ffigen.yaml, and instead rely on the lower bound constraints of the dependency on ffigen.
Like how language versioning works.
But whatever goes, might not be worth overthinking this. Most users will not be using ffigen directly, and most package authors will have at least some tests that the generated output works :)
I would suggest avoiding a version number on ffigen.yaml, and instead rely on the lower bound constraints of the dependency on ffigen.
Like how language versioning works.
That doesn't work if we only rely on on the json/yaml schema support in json/yaml editors. That would only work if we add the implementation to the dartcode plugin.
About versioning, you should add a version field to the ffigen.yaml format.
Then you should be able to use JSON schema conditionals to have specific schemes for each version.
That would mean we need to keep the definition of older config versions around in the Dart code that generates the schema. While that might be handy for something that wants to be able to interact with version skew, we don't want that kind of complexity in the FFIgen config parsing. I think it's a fair compromise to only support the newest schema. Users should upgrade to the newest version in most cases anyway.
(As someone who already experienced the XML craze, with XML schemas everywhere, that which JSON was the non-bloated response to, I guess we're getting closer to the next revolution. 😉)
(I guess we're part of the bloat now by wanting to give our users the extra user experience... 😆 )
Activity
HosseinYousefi commentedon Jun 5, 2023
Tangential – yaml schema for the rest of ecosystem
@DanTup I'm seeing that the pubspec schema in schemastore is also written by the community (as well as dart test and dart build). Thanks to @simolus3!
We could rely on the YAML extension and schemastore (not sure about support in other IDEs/editors), but we could also add the schemas to Flutter and Dart extensions + automatically generate the new schemas.
An advantage of having the schema validation as a part of Flutter/Dart extensions is the fact that we can load the correct version based on the project's Flutter/Dart version.
cc @jonasfj from the pub side of things. I think supporting schema/auto completion is a "nice to have". How hard is it to maintain it though?
cc @dcharkes
DanTup commentedon Jun 5, 2023
I'm not sure if I understand the suggestion here. Do you mean for the Dart extension to parse the schema and validate the YAML file? That feels out-of-scope for the Dart extension itself, but perhaps some validation/code completion could/should be done by the Dart analysis server?
It's the Dart analysis server that provides validation and code completion inside
pubspec.yamlandanalysis_options.yaml. It doesn't currently do it via a schema but has its own code for this (some of the things it does could not be represented in a schema) but it also knows what version of the SDK is being used (I'm not familiar with ffigen, but presume it's an SDK tool and therefore versions with the SDK?).(FYI @bwilkerson)
HosseinYousefi commentedon Jun 5, 2023
Oh, OK. I had the YAML extension installed so didn't realize that Dart analysis server already provides validation and code completion for
pubspec.yamlandanalysis_options.yamland assumed the YAML extension is using the available schema.ffigenis maintained by us so we could technically add the parser/validator/completer to analysis server. However, I don't think we need much more than a simple JSON Schema so maybe that's an overkill!DanTup commentedon Jun 5, 2023
If we want to provide this and not rely on a third-party extension, it might be the simplest way. Adding it to the Dart extension outside of the server would likely be more involved (and generally we try to keep things in the language server where they can be used by all editors and not just VS Code).
bwilkerson commentedon Jun 5, 2023
I'd be fine having this support in the analysis server, and I believe that's where it belongs.
The support we have code code completion is essentially equivalent to a schema, though it's closer to a procedural implementation than a declarative one. See https://github.com/dart-lang/sdk/blob/main/pkg/analysis_server/lib/src/services/completion/yaml/analysis_options_generator.dart#L22 for an example.)
The biggest difference is that we have the ability to add some non-generic logic when doing so makes sense in order to provide a slightly better experience.
We can also sometimes do a more complete job of validation than can be done using only a schema because we can check for constraints that can't be expressed in a schema.
Whether it's overkill depends, at least in part, on how often users edit
ffigen.yamland how difficult it is for them to get it right.dcharkes commentedon Jun 5, 2023
It sounds slightly overkill to me.
Though, if someone wants to volunteer for giving our users top-notch user experience, I'm not opposed to it. As long as we generate the implementation from the config spec in FFIgen so that maintenance burden is minimal.
A schema is probably good enough.
HosseinYousefi commentedon Jun 5, 2023
I checked the link and it's quite nice and simple to implement. I wouldn't assume generating a "producer" is harder than the JSON schema.
"Producer" seem to only be useful for completion purposes, it still won't "validate" the data type like JSON schema. But, I think that completion is a much nicer feature than validation – at least for
ffigenandjnigen.HosseinYousefi commentedon Jun 5, 2023
I completely agree, my concerns are:
ffigenthat you're using.dcharkes commentedon Jun 5, 2023
True, but we don't change the config that often.
Doesn't everyone have a ton of editors installed in VSCode anyway?
That's not a big issue right? Maybe we can automate that from the Dart CI even.
We could just put it somewhere in this repo, and always have all examples / samples / templates already have a reference to it.
In any case, now we have no schema, so every solution is an upgrade. 👍
HosseinYousefi commentedon Jun 6, 2023
Fair enough.
lrhn commentedon Jun 28, 2023
No, we don't. :)
(I have absolutely no confidence that all officially available plugins have been properly security-vetted, before being let loose on my potentially proprietary code. Doesn't mean I don't add extensions, I just try to reduce the attack area by not installing too many.)
About versioning, you should add a version field to the ffigen.yaml format.
Then you should be able to use JSON schema conditionals to have specific schemes for each version.
Say:
{ "type": "object", "if": { "properties": { "version": { "const": 2 } } }, "then": { "properties": { ...version 2 schema... } }, "else": { "if": { "properties": { "version": { "const": 1 } } }, "then": { "properties": { ...version 1 schema... } }, "else": { "properties": { ...original unversioned format scheme... } } } }(As someone who already experienced the XML craze, with XML schemas everywhere, that which JSON was the non-bloated response to, I guess we're getting closer to the next revolution. 😉)
jonasfj commentedon Jun 28, 2023
I would suggest avoiding a version number on
ffigen.yaml, and instead rely on the lower bound constraints of the dependency onffigen.Like how language versioning works.
But whatever goes, might not be worth overthinking this. Most users will not be using ffigen directly, and most package authors will have at least some tests that the generated output works :)
dcharkes commentedon Jun 28, 2023
That doesn't work if we only rely on on the json/yaml schema support in json/yaml editors. That would only work if we add the implementation to the dartcode plugin.
That would mean we need to keep the definition of older config versions around in the Dart code that generates the schema. While that might be handy for something that wants to be able to interact with version skew, we don't want that kind of complexity in the FFIgen config parsing. I think it's a fair compromise to only support the newest schema. Users should upgrade to the newest version in most cases anyway.
(I guess we're part of the bloat now by wanting to give our users the extra user experience... 😆 )
[ffigen] Symbol file import export (dart-lang#468)