Shared codecs package #153
Conversation
# Conflicts: # pnpm-lock.yaml
|
@zachferland if it looks OK to you do you mind if I publish the new package once the PR is merged please? |
| /** | ||
| * Passthrough codeco codec for CID. | ||
| */ | ||
| export const cid = new Type<CID, CID, unknown>( |
There was a problem hiding this comment.
does it make sense to have the ipld ones here? didnt see where they were used
There was a problem hiding this comment.
oh saw what you said before, since js-ceramic depends on dids dependencies
There was a problem hiding this comment.
Yes we need it here as well to define the DagJWS codec: https://github.com/ceramicnetwork/js-did/pull/153/files#diff-381c167d850c6491abefda0be2d4d6616083316c929a147f759358602a031592R14
| @@ -40,13 +40,13 @@ ___ | |||
|
|
|||
| ### cacao | |||
|
|
|||
| • `get` **cacao**(): `Cacao` | |||
| • `get` **cacao**(): `MapIn`<`RequiredProps`<{ `h`: `ExactCodec`<`TypeCodec`<{ `t`: `KeyOfCodec`<{ `caip122`: ``null`` ; `eip4361`: ``null`` }\> }\>\> ; `p`: `SparseCodec`<{ `aud`: `TrivialCodec`<`string`\> ; `domain`: `TrivialCodec`<`string`\> ; `exp`: `OptionalCodec`<`TrivialCodec`<`string`\>\> ; `iat`: `TrivialCodec`<`string`\> ; `iss`: `TrivialCodec`<`string`\> ; `nbf`: `OptionalCodec`<`TrivialCodec`<`string`\>\> ; `nonce`: `TrivialCodec`<`string`\> ; `requestId`: `OptionalCodec`<`TrivialCodec`<`string`\>\> ; `resources`: `OptionalCodec`<`Codec`<`string`[], `string`[], `unknown`\> & { `item`: `TrivialCodec`<`string`\> }\> ; `statement`: `OptionalCodec`<`TrivialCodec`<`string`\>\> ; `version`: `TrivialCodec`<`string`\> }\> ; `s`: `OptionalCodec`<`ExactCodec`<`TypeCodec`<{ `s`: `TrivialCodec`<`string`\> ; `t`: `KeyOfCodec`<{ `eip1271`: ``null`` ; `eip191`: ``null`` ; `solana:ed25519`: ``null`` ; `stacks:secp256k1`: ``null`` ; `tezos:ed25519`: ``null`` }\> }\>\>\> }\>, `$TypeOf`\> & `MapIn`<`OptionalProps`<{ `h`: `ExactCodec`<`TypeCodec`<{ `t`: `KeyOfCodec`<{ `caip122`: ``null`` ; `eip4361`: ``null`` }\> }\>\> ; `p`: `SparseCodec`<{ `aud`: `TrivialCodec`<`string`\> ; `domain`: `TrivialCodec`<`string`\> ; `exp`: `OptionalCodec`<`TrivialCodec`<`string`\>\> ; `iat`: `TrivialCodec`<`string`\> ; `iss`: `TrivialCodec`<`string`\> ; `nbf`: `OptionalCodec`<`TrivialCodec`<`string`\>\> ; `nonce`: `TrivialCodec`<`string`\> ; `requestId`: `OptionalCodec`<`TrivialCodec`<`string`\>\> ; `resources`: `OptionalCodec`<`Codec`<`string`[], `string`[], `unknown`\> & { `item`: `TrivialCodec`<`string`\> }\> ; `statement`: `OptionalCodec`<`TrivialCodec`<`string`\>\> ; `version`: `TrivialCodec`<`string`\> }\> ; `s`: `OptionalCodec`<`ExactCodec`<`TypeCodec`<{ `s`: `TrivialCodec`<`string`\> ; `t`: `KeyOfCodec`<{ `eip1271`: ``null`` ; `eip191`: ``null`` ; `solana:ed25519`: ``null`` ; `stacks:secp256k1`: ``null`` ; `tezos:ed25519`: ``null`` }\> }\>\>\> }\>, `$TypeOf`\> | |||
There was a problem hiding this comment.
is there no nicer way to show the types in the docs? seems like it decreases readability across a lot of the docs
There was a problem hiding this comment.
Yeah I agree it makes the generated type definitions ugly, @ukstv any idea if that could be worked around when using codeco's TypeOf please? Maybe using something like type-fest's Simplify?
| import { refinement, string } from 'codeco' | ||
| import type { Opaque } from 'ts-essentials' | ||
|
|
||
| export type DIDString = Opaque<string, 'DIDString'> |
There was a problem hiding this comment.
looks like later we could add stricter codecs for each did:key/pkh?
There was a problem hiding this comment.
Yes we can always add stricter codecs as needed, would be nice indeed to check for actually supported DID methods.
|
Good question about the return types, I'm not sure what the behavior will be so should be safer to use major versions increases. |
|
thanks for adding changesets! want to update the release section here? https://github.com/ceramicnetwork/js-did/blob/main/DEVELOPMENT.md |
Yes good call, I will do it on Monday! |
# Conflicts: # .changeset/config.json # packages/cacao/src/siwx/siwx.ts # pnpm-lock.yaml
|
@zachferland I updated the instructions, can you have a look please? |
In line with starting to use codecs in js-ceramic, I think it would be useful to have a codecs package for the DIDs structures, that could also be used in the js-ceramic codecs package considering the overlaps for some types.
Opening as draft to start the discussion, but will need more tests and docs.@ukstv it seems there is a conflict with using bothtypeandnamespacefor theCacaoexport, any idea how to address this please? If not, I think I'll rename the type toCacaoTypeto avoid the conflict, what do you think please?