Dependency discovery

[keithlayne]

For the purpose of cross-linking, this seems potentially tricky.

On one hand, you could examine package.json and just go with top-level runtime deps. That could be an okay first cut but would be suboptimal for lots of reasons.

Would be nice if we could use typedoc/compiler API/whatever to determine actual dependencies. This seems problematic possibly, but maybe I'm overthinking it. I was considering module resolution - but I know TS doesn't handle for example imports and exports yet in `package.json.

This is mainly future brainstorming. Please correct any bad assumptions I've made.

[cspotcode]

Using typedoc or the compiler API would avoid false-positives, because dependencies in package.json may not be referenced in the type declarations.

I wonder, typedoc has options to configure what is and is not considered an "external" type. Maybe it can help.

[keithlayne]

I was also thinking of how lots of people screw up runtime/dev/peer deps, but I imagine that's more end users and not lib autthors.

I was thinking of some other issues but I think I'm worrying about stuff that we should punt on for now.

[cspotcode]

Right now I have the worker script capturing logs when it fails and uploading them to GH pages. So we'll be able to browse the errors later and see if any libs are making common mistakes.

…

On Wed, Jul 14, 2021, 5:16 PM Keith Layne ***@***.***> wrote: I was also thinking of how lots of people screw up runtime/dev/peer deps, but I imagine that's more end users and not lib autthors. I was thinking of some other issues but I think I'm worrying about stuff that we should punt on for now. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OEPB3DIIC7EV3OXK3LTXX5ERANCNFSM5AMECF7A> .