Irakli Gozalishvili

Somewhat relevant though. IPLD resolvers & selectors would probably need some parameterization support - If issued GraphSync query is for composite IPLD there will needs to be a way to...

/cc @vmx as only thing I know about GraphSync is from his talk at Labs Day.

> We're planning to have multiple kinds of Node implementation, where individually each provides some interface for traversing one path segment / step at a time and yielding another Node;...

> One good point that I need to make sure we keep in mind is, that we can pass one some auxiliary data/context. In this case the crypto keys. It's...

I'm also starting to think that maybe there IPLD blocks should have some metadata on how to unpack it (which could be decrypt, or parse or whatever) and have process...

> Do we need to publish the type definitions in separate files when we already have the annotations? Is tsc unable to parse the types out of dependencies with it?...

> Is this something we would want to subject users to for the sake of getting rid of tooling? (I'm guessing no, but wanted to put it out there anyway)...

> Remove the types, typesVersions, and types fields from package.json This would break bunch of things. Only new TS supports `exports` field meaning libraries that aren't on newest one will...

Other that that what I pointed above plan sounds really good to me. In other words I'd just keep `types` and `typeVersions` until exports map becomes default in TS world...

> Would you mind enumerating which TypeScript versions must be supported for this effort? I could make sure to test against it. @RangerMauve I can't really speak to that. All...