-
Notifications
You must be signed in to change notification settings - Fork 53
chore(docs): allow to use .mdx format in docs #330
Conversation
Codecov Report
@@ Coverage Diff @@
## master #330 +/- ##
=======================================
Coverage 91.84% 91.84%
=======================================
Files 41 41
Lines 1337 1337
Branches 168 193 +25
=======================================
Hits 1228 1228
Misses 105 105
Partials 4 4 Continue to review full report at Codecov.
|
We need babel to wrap prop types again, strip debug statements from prod builds, and generate handled props. So I think this is inevitable. I like the idea of easily editable docs. However, we also loose typings / highlighting in doc pages by doing this. In comparing the added dependencies/complexity to use markdown in docs compared to how many doc edits we get, I'm not sure the tradeoff is worth it. I think I'd prefer less deps and a simpler build opposed to easier contributing path. Why? I don't think we'll have that many contributions compared to our own wrangling of the extra code and logic. Feedback? |
It's not usual markdown, this is mdx format. Formatting will be support by Prettier in the next release, VSCode has already a plugin (mdx-js/mdx#119), I'm think that Webstorm will support it soon, too. |
…ore/use-mdx # Conflicts: # docs/src/routes.tsx # docs/src/views/QuickStart.tsx
MDX support by @hughreeling I dont tried Docz, it may be an option. |
…rdust-ui/react into chore/use-mdx # Conflicts: # docs/src/routes.tsx # docs/src/views/QuickStart.tsx
I've updated |
We will definitely go with a prebuilt solution, most of them support MDX out of the box. |
I made similar thing for SUIR recently, now I want to ship it there and and simplify your life 🐱
Pros
Cons
awesome-typescript-loader
or events-loader
work, it always fails with [at-loader]: Child process failed to process the request: TypeError: Cannot read property 'externalModuleIndicator' of undefined s-panferov/awesome-typescript-loader#561