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
We should add a step somewhere in the build process to report an error if configuration-schema.json isn't found.
This will need designing. Not all adaptors have a credential schema so maybe it's a warning rather than an error.
This could be a build step in the build tools simply to check if the schema exists.
Alternatively, we could introduce a new validation tool (and this is probably where I lean, but with caveats). This could analyse either a built tarball or an adaptor's source. It should report on things like whether the adaptor has an ast.json, a docs folder and a configuration-schema.json. Maybe it could validate the package.json to ensure a standard build script etc.
In practice I'm a bit worried about this... what if there's an ast.json but it's an empty array because there's little or no jsdoc? What about packages which just don't have the schema yet? Should it throw warnings or prevent a build, merge or even release of the adaptor? Is this not just a human level thing to check in a PR before merging? In which case it's solved by #14.
It's probably more important to check that, if a schema file does exist in the repo, it also exists in the built tarball. Which points to a validation tool which runs on the built package. Which would be neat!
Simple ast already does a bunch of validation on docs. Could it inherit the responsibility?
The text was updated successfully, but these errors were encountered:
We should add a step somewhere in the build process to report an error if
configuration-schema.json
isn't found.This will need designing. Not all adaptors have a credential schema so maybe it's a warning rather than an error.
This could be a build step in the build tools simply to check if the schema exists.
Alternatively, we could introduce a new validation tool (and this is probably where I lean, but with caveats). This could analyse either a built tarball or an adaptor's source. It should report on things like whether the adaptor has an
ast.json
, adocs
folder and aconfiguration-schema.json
. Maybe it could validate the package.json to ensure a standard build script etc.In practice I'm a bit worried about this... what if there's an ast.json but it's an empty array because there's little or no jsdoc? What about packages which just don't have the schema yet? Should it throw warnings or prevent a build, merge or even release of the adaptor? Is this not just a human level thing to check in a PR before merging? In which case it's solved by #14.
It's probably more important to check that, if a schema file does exist in the repo, it also exists in the built tarball. Which points to a validation tool which runs on the built package. Which would be neat!
Simple ast already does a bunch of validation on docs. Could it inherit the responsibility?
The text was updated successfully, but these errors were encountered: