- 
          
 - 
                Notifications
    
You must be signed in to change notification settings  - Fork 19
 
Description
Initial checklist
- I read the support docs
 - I read the contributing guide
 - I agree to follow the code of conduct
 - I searched issues and discussions and couldn’t find anything (or linked relevant results below)
 
Problem
Being nitpicky and understandably may not be worth the effort. I notice shiki, which depends on this library has a large dependency graph due to mdast-util-to-hast.
mdast-util-to-hast is only used for types, however I think it's included as it's still used in the generated .d.ts files, like lib/handle/raw.d.ts and lib/handle/text.d.ts. The unique case here though is that those .d.ts files aren't actually imported by the entrypoint index.d.ts file (transitively).
So for most users interacting only with the public API, mdast-util-to-hast isn't really useful. But for those manually navigating to lib/handle/raw.d.ts or lib/handle/raw.js for some reason, it could be useful (but I think it's rare and not worth it).
Current solutions
Leave it as is, or patch the package.
Proposed solutions
- 
Since
mdast-util-to-hastis never imported by the entrypoint public API, we can safely movemdast-util-to-hastas a dev dep and not affect most users. - 
But if preserving proper types for those who navigate into
lib/handle/raw.d.tsandlib/handle/text.d.tsis important to you, then that's fine too and leave things as is. (though I'll be a little bummed for sure 😄)