feat!: Use schema stuff in the capabilities instead of custom parsing #220
Conversation
Gozala
changed the title
Gozala
force-pushed
the
feat/nb-schema
branch
from
f5936df
to
0e1880a
Compare
| }) => new Capability({ derives, nb, ...etc }) | ||
|
|
||
| const defaultNBSchema = | ||
| /** @type {Schema.MapRepresentation<any>} */ |
There was a problem hiding this comment.
| /** @type {Schema.MapRepresentation<any>} */ | |
| /** @type {Schema.MapRepresentation<unknown>} */ |
not sure if this makes sense but just an idea..
There was a problem hiding this comment.
No this is not going to work I'm afraid because it's used as default parameter for generic object schema and anything but any would fail to meet that requirement.
Ideally TS would respect default type parameter and allow matching it with default parameter in the function, but sadly it doesn't work so this is the only workaround I'm aware of
| @@ -1503,10 +1506,10 @@ test('capability with optional caveats', async () => { | |||
| const Echo = capability({ | |||
| can: 'test/echo', | |||
| with: URI.match({ protocol: 'did:' }), | |||
| nb: { | |||
| nb: Schema.struct({ | |||
There was a problem hiding this comment.
wdyt of trying to make things backward incompatible so code like nb: { message: URI } still works even without wrapping with Schema.struct?
There was a problem hiding this comment.
I wanted to, but amount of added complexity coupled with the fact that TS inference gets confused on occasions I don’t think it would be worth it
capabilitylogic came before theSchemadid we have not got around to integrating schema fully intocapabilitywe even end up with bunch of code that duplicated logic that is in schema.Consequently it became impossible to use Schema.struct or Schema.dict on the
nbfield. This PR updatescapabilityto just useSchema.