OCDkirby

> we can re-export types and publish them, seems reasonable Any implementation guidance? I can bang out some commits on a draft PR that will enable me to start on...

hosting as an npm package is a great idea. The syntax for their shorthand is `@user/package`, and just `package` works if it's unambiguous. `@quartz` is taken, could we do `@quartz-md/types`?...

Working layout of the exports: - `Plugin`: types from `plugins/types` - `Component`: types related to components, such as those in `components/types` - `Options`: configuration types used globally, at build time,...

Sounds good. I've been making changes in https://github.com/OCDkirby/quartz-api and testing with @MaelImhof 's https://github.com/OCDkirby/quartz-pseudocode/tree/QuartzAPI, let me know how you want to proceed with moving stuff over. Should I clean it...

@jackyzha0 looking at exporting the CLI types, but they're defined in JS as constants. Can I make a PR for some `.d.ts` files for so I can re-export them from...

I just realized, there's an interesting practical effect of the re-export route: A user's Quartz installation will depend on itself as a dependency of a dependency of a dependency if...

Perfect! PR incoming once I test that this works with a real plugin

The types aren't shared, the way we decided to implement is just re-exporting. Nothing about base quartz changes (yet) ```mermaid graph TD; Q[Quartz itself] T[Types re-exported] P[Plugins] Q --> P...

Gotcha, let me go fix that haha

> 1. We should have a template Quartz plugin people can fork (outside of this repository) with the right files to get started Seconded; the guide is in the docs...