diff --git a/website/docs/contributing.md b/website/docs/contributing.md index 86a93873fc..86bace34da 100644 --- a/website/docs/contributing.md +++ b/website/docs/contributing.md @@ -138,7 +138,7 @@ Please make sure the following is done when submitting a pull request: 1. Fork [the repository](https://github.com/facebook/docusaurus) and create your branch from `master`. 2. Add the copyright notice to the top of any code new files you've added. -3. Describe your [**test plan**](#test-plan) in your pull request description. Make sure to [test your changes](https://github.com/facebook/docusaurus/blob/master/admin/testing-changes-on-Docusaurus-itself.md)! +3. Describe your [test plan](#test-plan) in your pull request description. Make sure to [test your changes](https://github.com/facebook/docusaurus/blob/master/admin/testing-changes-on-Docusaurus-itself.md)! 4. Make sure your code lints (`yarn prettier && yarn lint`). 5. Make sure your Jest tests pass (`yarn test`). 6. If you haven't already, [sign the CLA](https://code.facebook.com/cla). diff --git a/website/docs/design-principles.md b/website/docs/design-principles.md index 5593332c25..c04a3ed0f2 100644 --- a/website/docs/design-principles.md +++ b/website/docs/design-principles.md @@ -5,11 +5,11 @@ title: Design Principles _This section is a work in progress._ -- **Little to learn** - Docusaurus should be easy to learn and use as the API is quite small. Most things will still be achievable by users, even if it takes them more code and more time to write. Not having abstractions is better than having the wrong abstractions, and we don't want users to have to hack around the wrong abstractions. Mandatory talk - [Minimal API Surface Area](https://www.youtube.com/watch?v=4anAwXYqLG8) +- **Little to learn** - Docusaurus should be easy to learn and use as the API is quite small. Most things will still be achievable by users, even if it takes them more code and more time to write. Not having abstractions is better than having the wrong abstractions, and we don't want users to have to hack around the wrong abstractions. Mandatory talk - [Minimal API Surface Area](https://www.youtube.com/watch?v=4anAwXYqLG8). - **Intuitive** - Users will not feel overwhelmed when looking at the project directory of a Docusaurus project or adding new features. It should look intuitive and easy to build on top of, using approaches they are familiar with. - **Layered architecture** - The separations of concerns between each layer of our stack (content/theming/styling) should be clear - well-abstracted and modular. - **Sensible defaults** - Common and popular performance optimizations and configurations will be done for users but they are given the option to override them. -- **No vendor-lock in** - Users are not required to use the default plugins or CSS, although they are highly encouraged to. Certain lower-level infra level stuff like React Loadable, React Router are fine, but not higher level ones, such as choice of Markdown engines, CSS frameworks, CSS methodology. +- **No vendor-lock in** - Users are not required to use the default plugins or CSS, although they are highly encouraged to. Certain core lower-level infra level pieces like React Loadable, React Router cannot be swapped because we do default performance optimization on them. But not higher level ones, such as choice of Markdown engines, CSS frameworks, CSS methodology will be entirely up to users. ## How Docusaurus works diff --git a/website/docs/migration-from-v1-to-v2.md b/website/docs/migrating-from-v1-to-v2.md similarity index 99% rename from website/docs/migration-from-v1-to-v2.md rename to website/docs/migrating-from-v1-to-v2.md index 0843f709f4..2c1626e587 100644 --- a/website/docs/migration-from-v1-to-v2.md +++ b/website/docs/migrating-from-v1-to-v2.md @@ -1,6 +1,6 @@ --- -id: migration-from-v1-to-v2 -title: Migration from v1 to v2 +id: migrating-from-v1-to-v2 +title: Migrating from v1 to v2 --- This doc guides you through migrating an existing Docusaurus 1 site to Docusaurus 2. diff --git a/website/docusaurus.config.js b/website/docusaurus.config.js index b89e26b769..741aa0ebdb 100644 --- a/website/docusaurus.config.js +++ b/website/docusaurus.config.js @@ -94,7 +94,7 @@ module.exports = { }, { label: 'Migration from v1 to v2', - to: 'docs/migration-from-v1-to-v2', + to: 'docs/migrating-from-v1-to-v2', }, ], }, diff --git a/website/sidebars.js b/website/sidebars.js index b6be2a5a52..54d56c11cc 100644 --- a/website/sidebars.js +++ b/website/sidebars.js @@ -29,7 +29,7 @@ module.exports = { 'using-plugins', 'using-themes', 'deployment', - 'migration-from-v1-to-v2', + 'migrating-from-v1-to-v2', ], 'Advanced Guides': [ 'advanced-plugins', diff --git a/website/src/pages/index.js b/website/src/pages/index.js index 6a16bb0c7e..b34196d772 100644 --- a/website/src/pages/index.js +++ b/website/src/pages/index.js @@ -27,10 +27,8 @@ const QUOTES = [ I've helped open source many projects at Facebook and every one needed a website. They all had very similar constraints: the documentation should be written in markdown and be deployed via GitHub - pages. None of the existing solutions were great, so I hacked my own and - then forked it whenever we needed a new website. I’m so glad that - Docusaurus now exists so that I don’t have to spend a week each time - spinning up a new one. + pages. I’m so glad that Docusaurus now exists so that I don’t have to + spend a week each time spinning up a new one. ), }, @@ -69,27 +67,25 @@ function Home() { -
-
-

+
+
+

Docusaurus with Keytar {siteConfig.title} makes it easy to maintain{' '} - - Open Source - {' '} + Open Source{' '} documentation websites.

-
+
Get Started - +