-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: move module declarations for non-route components to theme-classic #6629
Conversation
✔️ [V2] 🔨 Explore the source changes: bff1187 🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-2/deploys/62010c5bf97c180008646ce8 😎 Browse the preview: https://deploy-preview-6629--docusaurus-2.netlify.app |
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-6629--docusaurus-2.netlify.app/ |
Size Change: 0 B Total Size: 771 kB ℹ️ View Unchanged
|
@@ -43,6 +43,21 @@ declare module '@theme/BlogListPaginator' { | |||
export default BlogListPaginator; | |||
} | |||
|
|||
declare module '@theme/BlogSidebar' { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand this. change but not 100% satisfied either
We should find a way to decouple theme/plugin, and yet find a way to ensure correct end-to-end type-safety between theme/plugin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The plugin has absolutely no knowledge of @theme/BlogSidebar
, so it should definitely be in the theme's type def. Same with the others—I don't want to couple the theme design to the classic architecture too much, but delegate a lot of the freedom to the implementer side. FWIW, I even think each theme should have its unique themeConfig
options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see
The BlogPostPage uses types from @docusaurus/plugin-content-blog
so this looks fine/safe.
What surprised me is that it's the BlogSidebar that declares the sidebar prop, that type is then imported inside BlogPostPage
I'm not 100% which of those 2 components should "own" the type declaration (not sure if I'm clear 🤪 )
Motivation
Continuation of #6175. This fixes #6262 hopefully, and even if it doesn't, it's the best we can do. The theme aliases will be removed in the near future altogether, but for now, we will just put the components that the plugin directly references in the plugin typedef.
Have you read the Contributing Guidelines on pull requests?
Yes