* docs: add a note on the use of Prettier for MDX
* docs: add guides for Prettier users migrating to v3
* Update website/docs/guides/markdown-features/markdown-features-react.mdx
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* docs: Update MDX version
* Update website/docs/migration/v3.mdx
* Update v3.mdx
---------
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
This sentence contrasts authoring React with authoring CSS. The previous version did this in a way that makes the React authoring seem like a more advanced activity (“actual (…) code”), and authoring CSS the less advanced (described as “playing with”). The rewording tries to address that.
* Grammar fixes and minor clarifications
* Apply suggestions from code review
There's still a few pending ones that I posted replies on; I'll send those in a separate commit.
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Update website/docs/deployment.mdx
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Update website/docs/deployment.mdx
* PR 9150: made updates based on comments
* Prettier
---------
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
Co-authored-by: Sébastien Lorber <slorber@users.noreply.github.com>
* fix(core): Correct yarn version detection
Correct yarn version detection by checking `yarnPath` value inside `.yarnrc.yml` file
Add js-yaml in package.json
* Change to use `shelljs` instead of `js-yaml`
* Change echo mode to silent
* Check `yarn.lock` exist, before version checking
* Remove unnecessary optional chaining
Nullish coalescing operator still provides the fallback value
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
---------
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* attempt to support html embeds in mdx with format md
* refactor mdx loader + support embedding html in commonmark thanks to rehype-raw
* extract processor code
* refactor processor code
* extract format + unit test
* try to refactor processor
* try to refactor processor
* adjust md page
* do not apply rehype-raw when format is mdx
* fix lint issue
* fix: throw error for invalid URL in Docusaurus config file
* Also add unit test to check error is thrown
* fix: perform error check for invalid URL to configValidation.ts
* Throw error for invalid URL in Docusaurus config file
* Perform error check in configValidation.ts
* Undo error check in createSitemap.ts
* Better message
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* enhance: added ESLint ruler for CSS import
* chore: added ruler for default import of css, and fixed all exsting files
* chore: reverted changes on css header rulers
* docs: Correct link to document section
The link to the public API surface had an erroneous extra # in the link
preventing it from linking correctly.
* fix prettier
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* fix(theme-classic): fix Layout theme css height
This fixes html and body tags height from bug report
https://github.com/facebook/docusaurus/issues/7746
* Update styles.module.css
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* add theme-common/internal export
* Split @docusaurus/theme-common into public/internal apis
* fixes
* public <-> private
* public <-> private
* public <-> private
* fix
* add "removeThemeInternalReexport" CI script
* :s windows CI check not working: not that useful
* remove bad import
* refactors
* reorder
* make useBackToTopButton internal
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* fix: Expose empty string alt text in brand logos via nullish coalescing
* fix: Update boolean logic for fallbacks
* fix: Dogfood fix on Docusaurus brand logo
* refactor: Un-inline alt logic, and reduce chance of duplication in fallback
* add fast to showcase
* add fast png to showcase
* update tags, update website link, and upload new screenshot
* optimize image
Co-authored-by: Steph Huynh <steph@huynhicode.dev>
I've linked to the dev.to article (which is a timestamped stable version) - to be consistent with other deployment snippets.
The dev.to article references [this GitHub repo](https://github.com/fearlessly-dev/swa-demo-docusaurus) and this[#30DaysOfSWA](https://www.azurestaticwebapps.dev/blog/build-with-docusaurus) site which was the inspiration for writing this article. The repo contains the code for the demo, and its README is the canonical source for the article, in case relevant.
* fix(website): use react-lite-youtube-embed for lazy YouTube video
* fix(website): use react-lite-youtube-embed for lazy YouTube video
* fix(website): use react-lite-youtube-embed for lazy YouTube video
* Update multiple-sidebars.md
* Update installation.md
* refactor intro
* rename file back
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Revert "fix(core): handle case where package.json is not available at CWD (#7187)"
This reverts commit 3b32a41f22.
* properly fix
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Update installation.md
I believe the current version of Docusaurus requires node 16. With 14 I get:
```
import {program} from 'commander';
^^^^^^^
SyntaxError: The requested module 'commander' does not provide an export named 'program'
at ModuleJob._instantiate (internal/modules/esm/module_job.js:92:21)
at async ModuleJob.run (internal/modules/esm/module_job.js:107:20)
at async Loader.import (internal/modules/esm/loader.js:179:24)
```
* Update installation.md
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* docs: add Svix to showcase
Motivation
Svix uses Docusaurus for our documentation. It could be cool to add it in the showcase page.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Run yarn run start:v2 and check that the page http://localhost:3000/showcase is rendered properly.
Related PRs
No
* Add svix doc preview image
* Delete Svix.png
* re-upload preview image
needed to make file name lower case.
* optimize image
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Fixed several pairs of 'handle' and 'name', as their values were inverted.
* Apply suggestions from code review
* oops
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Changed blog name
Changed the name and domain for my Docusaurus based blog to fullstackchronicles.io
* added new screenshot
* updates
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* refactor(website): minor fixes and improvements
* Some fixes
* Round all the corners in browser window
* Add rounded bottom corners to browser window
* Correect Wrong file name
The file name inside the my-plugin folder is index.js .
* Update plugins.md
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* fix(types): declare history and react-loadable as dependencies
* fix(types): downgrade history to 4.9.0 to match react-router
* add @docusaurus/react-loadable such that it can be correctly resolved
* docs: remove unnecessary semicolon
The semicolon after the TOCInline component is unnecessary and actually gets rendered on screen.
* ignore prettier
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Fix example admonition syntax
There was a space between `::: info` should be `:::info` or else Docusaurus does not render it as an admonition.
* kick CI
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Correct npm run tsc to npm run typecheck
According to this page, you should run `npm run tsc` to run `tsc` and do a type check. However, in the package.json file for Docusaurus version 2.0.0-beta.17 the command is actually `npm run typecheck`, which runs `tsc`.
This update only replaces `tsc` with `typecheck` so the npm script will run correctly.
* Recommend npx tsc for type-checking
Based on feedback for the original change to replace `npm run tsc` with `npm run typecheck`, a better solution that was suggested was to use npx to run tsc instead of an npm script. `npx tsc` should work regardless of the template/presets you installed when you installed Docusaurus.
Remark and Rehype plugins allow having options as a non-object type,
such as a string.
For instance, the official MDX docs even have an example of this:
See https://mdxjs.com/docs/extending-mdx/#using-plugins
The official plugin `remarkjs/remark-frontmatter` allows passing
a string, e.g. `"toml"` as the options arg, instead of an object.
* fix(docs): warn when files are not tracked
* chore(devcontainer): use non-root user
* test: fix jest in vscode
* test(docs): improve existing test
* chore(devcontainer): fix jest error on startup
* chore: fix comments
* chore: remove "probably" from error message
* Clarify the usage of slug
As a new user it was unclear whether setting `slug` would change the URL relative to the root directory or relative to the docs directory. The example I added should make that clear without needing to test out the functionality in a Docusaurus instance (which is what I had to do).
* editorial changes
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* docs: add info about development on github codespaces
* docs: move from installation to cli
* docs: fix grammar
* Update cli.md
* add word
* Update cli.md
* Update cli.md
* format
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Add reddit-image-fetcher.png to showcase
* Add Reddit Image Fetcher to users.tsx
* Update reddit-image-fetcher.png with correct dimension
* optimize image
* Set Reddit Image Fetcher's source as `null` and remove open source tag
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* code block included diff +,-
Sample code block could not be copy/pasted as the tutorial mentions with the lines that appear to be from a diff tool.
* add highlight
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Fix a broken showcase GitHub URL
* Seems like this site is no longer Open Source?
* Seems like this site is no longer open source?
* Fix as previous link leaded to a 404
* Replaces the 404 error of previous page.
Not sure if this is the correct link to be placed there.
* Fixes 404 error ;)
* fix: consistently use `max-width: 996px` in media queries
Follow `docusaurus-theme-classic` and use `996px` as the cutoff
between desktop and mobile screen width.
* revert example changes
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* add Blog Matheus Brunelli to users.tsx
* add blogmatheusbrunelli.png to showcase
* minor tweaks
* add tag
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* chore(utils): add `removeTitle: false` to svg loader
By default, SVGR removes the `<title>` tag from SVG inputs.
This hinders a11y since "the `<title>` element provides an
accessible, short-text description of any SVG container
element or graphics element".
Modern browsers also show tooltips on hover for inline
SVG with the `<title>` tag.
See https://developer.mozilla.org/en-US/docs/Web/SVG/Element/title
* fix test
* refactor(theme-classic): clean up doc sidebar item CSS
* Use link placeholder for Introduction category
* Use test pages for dogfooding
* Update sidebars.js
* Add another test case
* fix example for id that didn't respect regex
example for id don't work with version 2.0.0-beta.15:
ValidationError: "id" with value "docs1" fails to match the required pattern: /^[a-zA-Z_-]+$/
Error: Process completed with exit code 1.
* properly fix
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Update docs-markdown-features.mdx
* Author meant to recommend the use of full paths rather than relative paths: Technical edit
* Revised intro to naturally introduce the benefits of this recommendation: Style edit
* Update website/docs/guides/docs/docs-markdown-features.mdx
* Update website/docs/guides/docs/docs-markdown-features.mdx
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Use React Strict Mode
Even though Strict Mode is not required a WARNING icon now displays
on all components that do not use React.StrictMode on React DevTools extension.
Signed-off-by: Shinwon Elizabeth Yoon <24852454+seyoon20087@users.noreply.github.com>
* Utilize react-helmet-async instead of react-helmet
react-helmet is NOT thread safe, as explained in https://open.nytimes.com/the-future-of-meta-tag-management-for-modern-react-development-ec26a7dc9183#fdc2
Therefore, it's better if react-helmet-async is utilized instead of react-helmet.
Even though react-helmet-async is being utilized, most users will not require any code changes to @docusaurus/Head since it uses the same API as react-helmet.
Signed-off-by: Shinwon Elizabeth Yoon <24852454+seyoon20087@users.noreply.github.com>
* Include HelmetProvider inside client entry
I forgot to do this before.
Signed-off-by: Shinwon Elizabeth Yoon <24852454+seyoon20087@users.noreply.github.com>
* format
* fix TS
* address reviews
* Remove forked react-loadable package in favor of @react-loadable/revised
Both unforked react-loadable and @docusaurus/react-loadable uses legacy React APIs.
However, @react-loadable/revised (https://github.com/react-loadable/revised) is actively maintained and widely used in production, thus replaced with this package.
Signed-off-by: Shinwon Elizabeth Yoon <24852454+seyoon20087@users.noreply.github.com>
* remove unused comma
* Address reviews from https://github.com/facebook/docusaurus/pull/6306#pullrequestreview-864745191
Signed-off-by: Shinwon Elizabeth Yoon <24852454+seyoon20087@users.noreply.github.com>
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Added the sitemap url
So that users know where to locate their sitemaps
* Update plugin-sitemap.md
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* fix: fix links to JSON from .md files
closes#3561
It seems to be a common problem that many people are having see:
https://stackoverflow.com/questions/65307533/link-to-static-json-file
Co-authored-by: Anthony McCaigue <anthony@nquiringminds.com>
Co-authored-by: Alois Klink <alois@nquiringminds.com>
* Add dogfooding examples
* actually fix
* oops
Co-authored-by: Alois Klink <alois@nquiringminds.com>
Co-authored-by: Josh-Cena <sidachen2003@gmail.com>
* Update users.tsx
Hi, we have changed our product name from InfraQL to StackQL and we have gone all in with Docusaurus - including the marketing site, docs and blog (previously it was just the docs and blog), authored a few plugins on npmjs as well if you are interested, love your work!
* added new homepage image
* fixes
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Added docs site for SODA for SPARC
* Added SODA for SPARC snapshot
* Update spelling error for path
* optimize image
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* fix: highlight appropriate navItem based on active sidebar item
* fix: try using location.pathname
* fix: remote console.log
* fix: include category generated indices in globalData
* Add test
* fix snap
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* chore: add baseline stylelint rules
Use the Prettier config so not to conflict with rules.
Add the Stylelint baseline recommended rules to catch additional lissues
* enable those two rules
* ooops
* refactor scripts
* revert script changes
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* chore: upgrade rehype-katex to latest version with ESM support and update the docs
* Update documentation to reflect ESM upgrade is currently optional
* rewording
* final tweaks
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* feat(theme-common): add smooth TOC scrolling to active link
* docs: change the link of repeated content category in lifecycle api
* Update lifecycle-apis.md
* fix page container scrolling
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* update(users.tsx): add personal website show case
* add icodex.png for personal webste showcase
* resize image
* optimize
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Showcase: Update images
* Showcase: Remove sites that are not working, and have not been working since yesterday.
* Suspected no longer using docusaurus (please confirm)
* Revert "Showcase: Remove sites that are not working, and have not been working since yesterday."
This reverts commit c963f120e9.
* add notices
* test screen resolution
* all of them
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Add Digital Support Notes to the showcase
Add Digital Support Notes to the showcase!
* Update users.tsx
* Add Digital Support notes to showcase
* Update screenshot
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* docs: refactor & refine lifecycle API docs
* Fix links
* More writeup
* Rewording
* Rename path
* Use README
* Fix links
* Add redirects
* Do the same for latest version as well
* Move folder
* Fix broken link
* Add extra Korean translation, fix typo
Signed-off-by: Yongmin Hong <revi@pobox.com>
* Add missing translations, per John-Cena's guidance
Resolves most comments, more fix.
Signed-off-by: Yongmin Hong <revi@pobox.com>
* Cleanup rebase and add one more translation
add the missing bit.
Signed-off-by: Yongmin Hong <revi@pobox.com>
Netlify now provides `*.netlify.app` subdomains instead of `*.netlify.com` for project sites. Redirects still work, so the current config option isn't wrong but it's a good idea to keep the docs up to date.
* refactor(website): add various fixes and improvements on Showcase page
* Maintain previous focused element (WIP)
* Fix SSR
* Fix again
* Final fix
Co-authored-by: Josh-Cena <sidachen2003@gmail.com>
* docs: improve algolia integration instructions
The current version makes it look like you need to install `@docusaurus/theme-search-algolia` on top the classic version to work, but it already works with the classic version. Adding `@docusaurus/theme-search-algolia` on top leads to errors.
* Still document installation
* Do not make separate paragraph
Co-authored-by: Josh-Cena <sidachen2003@gmail.com>
* feat: redesign of showcase page
* redesign of showcase card
* improved card design
* create Tooltip component, Svg component
* Add popper.js to dependency
* fixed netlify deploy issues
* fixed netlify deploy issues
* fixed netlify deploy issues
* Make things work
* Relock
* Refactor
Signed-off-by: Josh-Cena <sidachen2003@gmail.com>
* Fix linter errors
* Make animation shorter
* Refactors
* Do not make entire link clickable
* fixed linting and netlify deploy issues
* enhanced styles and fix deploy issues
* Polishing
* improved contrast for selected tags
* Refactors
* Make each component standalone
* Fix operator on first render
* Color coding!
* fix SSR
* More elegant impl
* Do not show source if there is not one
* Fix
* custom on-focus styling for focusable elements with default outlinline && highlight filter toggle on focus.
* fix lint issues
* restore highlight coloring
* Use state instead of ref
Signed-off-by: Josh-Cena <sidachen2003@gmail.com>
* Visual seperator
* Refactors
Signed-off-by: Josh-Cena <sidachen2003@gmail.com>
* Minor fix with dev server
* Paletter improvement
Signed-off-by: Josh-Cena <sidachen2003@gmail.com>
Co-authored-by: Josh-Cena <sidachen2003@gmail.com>
* fix(module-type-aliases): add svg, scss, module.scss, module.sass
* fix(module-type-aliases): css should be declared after module.css
* fix(module-type-aliases): remove scss related declarations
* fix(module-type-aliases): correct svg declaration
Co-authored-by: FISH UP <MisterFISHUP@users.noreply.github.com>
* refactor(remark-plugin-npm2yarn): migrate package to TS
* fix(remark-plugin-npm2yarn): type as unified Plugin
* refactor(remark-plugin-npm2yarn): standardize code style with remark plugins in mdx-loader
* Use unist-util-visit
* Use export =
* Remove unneeded includes option
* Fix tests
* Migrate test to TS
* Make output look better
Co-authored-by: Josh-Cena <sidachen2003@gmail.com>
* refactor: optimize clone and checkout in deploy command
* refactor: remove obsolete check for default branch and simplify flow
* refactor: skip cloning repository if deployment branch doesn't exist
* Refactors
* More tip about failure
Co-authored-by: Josh-Cena <sidachen2003@gmail.com>
* feat: allow GIT_USER env var to be unset if SSH is used
* fix: packages/docusaurus/src/commands/deploy.ts
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* feat: allow user to specify deploymentBranch property in docusaurus.config.js (#5841)
* feat: allow user to specify deploymentBranch property in docusaurus.config.js
* docs: remove extra backtick
* docs: fix broken code block
* docs: fix i18n routes to feature requests (#5843)
* docs: fix i18n routes to feature requests
* Add redirect rules
* feat: allow GIT_USER env var to be unset if SSH is used
* fix: packages/docusaurus/src/commands/deploy.ts
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* fix: avoid escaping hyphen in regex
* Refactor
* Update deployment.mdx
* Make SSH higher priority
* Only infer but not override
* Add tests
* Fix tests
* Fix
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* docs: Minor copy changes + increment numbered list
* docs: Add alternative github pages deploy workflow
* docs: Add separate PR workflow for alternative gh-pages deploy example
* docs: Minor `gh-pages` deploy config improvements
Improve some comments and clarifies the file path beyond file name alone for each config file.
Additionally removes the workflow path triggers as in practice these being updated shouldn't be triggering a re-run of the workflow again (assuming deterministic build from same input results in same output).
If there is a need for such a manual trigger of the workflow is probably a better approach. Performing a build because workflow comments were modified only would be pointless for example.
* docs: Clarify `gh-pages` deploy config some more
* chore: PR Feedback - Remove inline documentation
Upstream doesn't see value including help comments for a copy/paste config under the basis that it adds friction to the viewer seeking guidance how to perform something they don't know.
* chore: PR Feedback - Rephrase instruction
MatanBobi requested a rephrase during review.
* Rewrite
* Fixes
* Fix!
* Format
* Fix indentation
* Improvements
* Minor fixes
Co-authored-by: Josh-Cena <sidachen2003@gmail.com>
* SSH is required for GitHub deployment now
Matches what is listed in the default README.md of a new Docusaurus site
* Minimum node version required is 14.x
documentation.yml as written fails to run because the minimum node version for Docusaurus is 14.x
* Add link to default URL of locally-served site
* Correct deployment workflow
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Commit 66771bd80d renames the file v2-tests.yml to tests.yml
in PR #5833 which broke the github actions test icon and link to the workflow.
Signed-off-by: Hemant Sachdeva <hemant.evolver@gmail.com>
* feat: changed the logo properties to allow width/height specification
* fixup! feat: changed the logo properties to allow width/height specification
* fixup! feat: changed the logo properties to allow width/height specification
* Rework: add fields to logo object
* Fix
* More fixes
* Wrong width!
* No need for optional chaining
* Doc writeup
Co-authored-by: Josh-Cena <sidachen2003@gmail.com>
* Add cloudywithachanceofbigdata.com showcase site
Add [Cloudy with a chance of Big Data](https://cloudywithachanceofbigdata.com/) Docusaurus blog only site
* Added cloudywithachanceofbigdata.png
* fix: place root route at the end
* Use sorting independent of subroutes
* Add better test to cover edge-case and ensure "/" routes with child are at the end
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* fix: makes types DocusaurusConfig optional to match docs
* add UserDocusaurusConfig with required keys for user config
* convert UserDocusaurusConfig to use util type
* Docusaurus website config should be type-checked by CI + fix all existing issues
* add doc for config typechecking
* Update template configs for TS autocompletion
* fix last config typechecking bugs
* reapply prettier
* reapply prettier-docs
* Fix TS doc: add missing ()
* fix some docu plugin types
* add "const config" for simpler jsdoc annotation
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* docs: add additional search bar options - typesense and local search
* docs: add typesense docsearch to community resources
* improve search doc, explain better where to get support
* improve search doc
* improve search doc
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* Make urlLoaderLimit in the webpack config user-overridable via environment variable 'URL_LOADER_LIMIT'.
* Apply suggestions from code review
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* Changes as per @slorber's suggestions:
* moving it to packages/docusaurus/src/constants.ts
* name it WEBPACK_ URL_LOADER_LIMIT
* add comment to say it's temporary, link to this PR/issue
Co-authored-by: stnor <stefan@selessia.com>
Co-authored-by: Joshua Chen <sidachen2003@gmail.com>
* refactor: css variables for back to top button
* refactor: adjust back to top button styling
* Update from PR feedback
* err... darker.
* swap secondary color for emphasis scale
* reduce contrast further
* Add new translations
* Cleanup CSS
* Remove active state
Co-authored-by: Alexey Pyltsyn <lex61rus@gmail.com>
* Test escape pipe in Markdown table
From a remark on Crowdin:
> The value for the Type entry in the plugin-content-blog page is strange.
> In English documents, the Type item value is normally displayed.
> ex) editUrl: string | EditUrlFunction
> However, in French documentation, the Type item value is shown as an unknown code.
> ex) editUrl:!!crwdBlockTags_249_sgaTkcolBdwrc!!
> ex) blogSidebarCount: !!crwdBlockTags_250_sgaTkcolBdwrc!!
This is a test to see if the other way to escape a pipe in a markdown table could solve the problem.
* Fix all docs to replace | by \|
* Keep `code`
* Apply suggestions from code review
Co-authored-by: Alexey Pyltsyn <lex61rus@gmail.com>
* On back, close mobile navbar sidebar
* more reliable code to block history pop events
* android backbutton: just close the drawer without cancellin the backward navigation
* Update Arabic Translation
* Update Persian Translation
* fix spacing problem for ar.json
* fix spacing problem for fa.json
* Update fa.json
Update Persian translation to match with @farshidinanloo translation
* fix ar.json
* Update fa.json to match with @farshidinanloo
* feat: add metatags support for seo / blogposts
* feat: different implementation
* feat: use isBlogPostPage
* feat: implement in BlogPostPage-remove Seo changes
* Revert "feat: implement in BlogPostPage-remove Seo changes"
This reverts commit 1cba459b
* Move Seo to BlogPostPage + some fixes
* fix social preview asset
* Fix blog social image + improve a bit Seo setup
* fix bootstrap theme
Co-authored-by: John <john.reilly@investec.co.uk>
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* Better Canny integration
* Add missing netlify redirects
* polish
* TS doc: mention it's possible to use JSDoc in config
* issue templates: use /feature-requests new url
* fix Locale dropdown IconLanguage RTL margin
* add more alias test fixtures for nested elements
* change webpack alias ordering logic to handle nested items better
* another aliases order fix
* [v2] tags to doc, same as tags to blog - [IN PROGRESS]
- Addition of plugin-content-docs
- Addition of DocTagsListPage in `docusaurus-theme-classic`
! Error exists for this commit towards the theme aspect and help required.
Commit towards #3434
* docs: make tags list page work
* temp: disable onBrokenLinks
* theme bootstrap: create DocTagsListPage
* DocTagsPage added and functionality too
- individual doc tag page added to show docs for that specific tag
* Added all Docs Tags Link
* add some shared tag utils
* move tag tests to _dogfooding
* fix type
* fix some tests
* fix blog test
* refactor blog post tags handling
* better yaml tag examples
* better dogfood md files
* refactor and factorize theme tag components
* finish DocTagDocListPage
* Extract DocItemFooter + add inline tag list
* minor fix
* better typings
* fix versions.test.ts tests
* add tests for doc tags
* fix tests
* test toTagDocListProp
* move shared theme code to tagUtils
* Add new theme translation keys
* move common theme code to tagUtils + add tests
* update-code-translations should handle theme-common
* update french translation
* revert add translation
* fix pluralization problem in theme.docs.tagDocListPageTitle
* add theme component configuration options
* add more tags tests
* add documentation for docs tagging
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* doc: docusaurus-preset-name does not exist and is confusing for some users
* doc: docusaurus-preset-name does not exist and is confusing for some users
* fix: All navbar items without sidebar are active
Close All navbar items without sidebar are active #5310
* Update packages/docusaurus-theme-classic/src/theme/NavbarItem/DocNavbarItem.tsx
Co-authored-by: Alexey Pyltsyn <lex61rus@gmail.com>
Co-authored-by: Alexey Pyltsyn <lex61rus@gmail.com>
* POC of blog post folder
* add parseBlogFileName with tests + refactor and extract processBlogSourceFile in separate method
* improve blog date pattern doc + link from content plugin guides to API ref docs
* Some FrontMatter fields should be able to reference relative image assets, converted to Webpack require calls and exposed as frontMatterAssets
* remove log
* move deep filepath test
* split markdownPageExample.md
* re-org dogfooding content
* Add mdx partials fallback synthetic plugin by default
* test commit
* hide changelog title as it's already included in the partial file
* trigger CI
* fix changelog sidebar label
* Type docs version
Signed-off-by: Josh-Cena <sidachen2003@gmail.com>
* Move non-null assertions
Signed-off-by: Josh-Cena <sidachen2003@gmail.com>
* Test again
* feat(v2): add back to top button
* Test on mobiles
* Use clean-btn class
* Fix case
* clearer useScrollPosition() hook
* fix useScrollPosition typing + dangerous 0 fallback value + refactor a bit backToTop button
* useless fallback
* Handle both browsers with/without native smooth scrollBehavior support
* fix SupportsNativeSmoothScrolling using document on SSR
* revert to smoothScrollTopPolyfill usage
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* Details component
* polish arrow animation
* fix text selection bug
* fix some edge cases + polish
* example of overriding baseClassName
* Move Details component to theme-common
* make component work even when JS is disabled or failed to load
* update arrow transform
* Details component: better handling of no-JS fallback mode: avoid delaying arrow navigation when JS (see review)
* prefix css vars with --docusaurus
* improve css arrow styling
* slightly change details/summary design
* better md doc + include quotes and details in doc
* Fix handling of empty `dependencies` section.
In Flipper, https://github.com/facebook/flipper/blob/master/website/package.json, all our dependencies live in `devDependecies` of our `package.json`. As a result `dependencies` is not set, causing a crash when running `yarn start`:
```
/Users/mweststrate/fbsource/xplat/sonar/website/node_modules/@docusaurus/core/bin/docusaurus.js:50
const siteDocusaurusPackagesForUpdate = Object.keys(sitePkg.dependencies)
^
TypeError: Cannot convert undefined or null to object
at Function.keys (<anonymous>)
at Object.<anonymous> (/Users/mweststrate/fbsource/xplat/sonar/website/node_modules/@docusaurus/core/bin/docusaurus.js:50:50)
at Module._compile (internal/modules/cjs/loader.js:955:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:991:10)
at Module.load (internal/modules/cjs/loader.js:811:32)
at Function.Module._load (internal/modules/cjs/loader.js:723:14)
at Function.Module.runMain (internal/modules/cjs/loader.js:1043:10)
at internal/main/run_main_module.js:17:11
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
Setting `"dependencies": {}`, works as work around, but this patch fixes the crash, and makes sure the deps are upgraded as well if they live in `devDependencies` instead of `dependencies`.
* formatting fix
* Add _ to dogfood docs folder to cover against edge case
* Fix edge case with MDX partials when site / content dir contains a _ prefix
* add globUtils tests
* proper dogfooding folder re-organization, all content plugins being used
* refactor dogfooding folder + expose /tests page index
* fix page plugin ignoring options.routeBasePath
* Update markdown-features-code-blocks.mdx
if you add php language and don't restart your server, you will get an error like this
uncaught Error: Cannot find module './prism-php'
until you restart your server
* Update website/docs/guides/markdown-features/markdown-features-code-blocks.mdx
Co-authored-by: Sébastien Lorber <slorber@users.noreply.github.com>
* create a swizzleWarning partial for shared text
* Generalize usage of _ prefix convention to exclude content files/folders
* add api doc
* MDX loader should not expect metadata/frontmatter on MDX partial files
* Update deploy with Qovery docs for V2
Hello Docusaurus team,
I updated the docs for the new Qovery V2
https://www.qovery.com/blog/qovery-v2-beta-is-out
* run prettier on docs
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* feat(v2): mobile TOC
* Bug fixes and various improvements
* Redesign
* extract TOCCollapsible component
* TS improvements
* Assign sidebar name directly to the doc route => no need for either permalinkToSidebar or GlobalData
* revert changes to useWindowSize, fix FOUC issues
* extract DocSidebarDesktop component
* remove now useless menu infima classes
* TOCHeadings => rename + remove unused onClick prop
* Extract DocSidebarItem
* minor renaming
* replace GlobalData usage by a React teleport system to render in the navbar mobile sidebar menu directly from the DocPage component
* useWindowSize => simulate SSR size in dev to make FOUC issues more obvious
* fix remaining sidebar layout shift
* update docs snapshots
* remove unused code translations
* remove unused code translations
* fix minor update-code-translations bug
* Add more build-size paths to watch
* Restyle back button
* Add missing`menu` class
* extract useShallowMemoizedObject
* fix routes tests + better routes formatting
* use Translate api for labels
* use Translate api for labels
* Update translations
* Improve dark mode support for back button
* Merge branch 'master' into lex111/inline-color-code
# Conflicts:
# packages/core/dist/css/default-dark/default-dark-rtl.min.css
# packages/core/dist/css/default-dark/default-dark.min.css
# packages/core/dist/css/default/default-rtl.min.css
# packages/core/dist/css/default/default.min.css
* replace useCollapse by new useCollapsible
* Cleanup and use clean-btn for TOCCollapsible button
* Make TOC links clickable over full width
* Cleanup
* fix uncollapsible sidebar that can be collapsed + create <Collapsible> component
* dependency array typo
* rollback sidebars community commit typo
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* remove webpackConfig.resolve.symlinks: true
* Add docs-test docs plugin instance to validate using a symlink folder as docs source is possible
* comment
* useful comments
This was likely a typo, and resulted in the following error when using Typescript strict mode:
node_modules/@docusaurus/types/src/index.d.ts(250,14): error TS7031: Binding element 'Content' implicitly has an 'any' type.
* fix(v2): avoid slowdown transition with huge sidebar items
* move useCollapsible to theme-common
* @docusaurus/theme-classic => watch mode should include type-checking
* refactor useCollapsible => encapsulate more behavior / state / ref inside it, making code simpler for component using it
* useCollapseAnimation => animate DOM properties directly instead of using React inline styles => optimize perf from 4 render per click to 1 render per click
* add missing items in deps array
* rename ref to collapsibleRef
* lint
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* Rewrite markdown images section
Before it looked like we have two ways to display images, now it's three ways. Each syntax has a separate example.
This way it's clear, I see each method and the code example.
Before there were 2 methods in a single code block.
* fix typo in `markdown-features/markdown-features-assets`
Co-authored-by: Sébastien Lorber <slorber@users.noreply.github.com>
* Rewrite image display section using CommonJS require
Co-authored-by: Sébastien Lorber <slorber@users.noreply.github.com>
* Rewrite image display section using ES imports
Co-authored-by: Sébastien Lorber <slorber@users.noreply.github.com>
* prettier doc
Co-authored-by: Sébastien Lorber <slorber@users.noreply.github.com>
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* never apply trailingSlash to site root ('/baseUrl/') => only subroutes
* add deprecation comment for loadContext.baseUrl in favor of loadContext.siteConfig.baseUrl
* commit typo
* useless code
* Sitemap should respect the global trailingSlash config option.
* improve tests for createSitemap / trailingSlash
Co-authored-by: slorber <lorber.sebastien@gmail.com>
In some cases, negative sidebar positions can be useful for reversing
the sorting order with minimal maintenance overhead. For example, a docs
folder with changelogs for historical versions should be sorted in
reverse chronological order. This is easy to do for semantic version
numbers by converting them into a negative numerical representation,
e.g. 11.5.1 -> -110501.
The alternative is to make the first version start with a large position
number (e.g. 9999) and decrement it for each version. However, this
requires referring to older versions to get the current sequence number,
thus increasing maintenance overhead. It also makes the number less
intuitive and more prone to error.
Negative sidebar positions work great for this purpose, so make the
front matter validator allow them again as #4796 broke this use case.
* Divide `markdown-features/code-blocks` to smaller sections
This PR adds few more heading to split the content to small topics.
This way users like me will be able to scroll directly to the specific section, instead of reading all the documentation.
I add to read the entire section because It was not divided into sections. Not a great user experience.
* Use `<h3>` heading
* fix(types): type `LoadedPlugin` is not generic
`LoadedPlugin` referenced line 201 is not generic, causing typescript errors on
end-user builds.
* chore(types): add typescript dev dep, tsconfig and a test script
Contributors will no longer inadvertently dump type errors since any IDE should
check types now.
* add missing plugins generic types
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* refactor DocVersionBanner => versionMetadata prop should be forwarded instead of using "useActiveVersion" + global data
* docs version banner configuration
* add doc for versions.banner
* fix tests
* improve docs plugin option api doc
* fix: truncate docuhash return value in order to avoid ERRNAMETOOLONG error
* chore: add deep file path test page to website
* refactor: reorganize docuHash/pathUtils code and tests
* chore: git support longpaths on v2 windows tests workflow
Co-authored-by: slorber <lorber.sebastien@gmail.com>
* sidebar_label should be used to compute next/previous button texts, as documented.
* improve docs frontmatter doc
* use a little bit of destructuring
* POC: add trailingSlash option
* integrate the preferFoldersOutput option of fork @slorber/static-site-generator-webpack-plugin
* Fix broken links when using trailing slash => using md links is more reliable
* fix TS issue
* minor polish
* fix doc page being sensitive to trailing slashes
* Add tests for applyTrailingSlash
* rename test files
* extract and test applyRouteTrailingSlash
* update snapshot
* add trailing slash config to serve command
* fix getSidebar() => still sensitive to trailing slash setting
* never apply trailing slash to an anchor link
* Add documentation for trailingSlash setting
* refactor(v2): remove type attribute from link and script tags
* minor TS fix
* stylesheets.type => optional
Co-authored-by: slorber <lorber.sebastien@gmail.com>
// Array#at is ES2022; could replace _.nth as well
// ['last'],
['map','Array#map'],
['reduce','Array#reduce'],
['reverse','Array#reverse'],
['slice','Array#slice'],
['take','Array#slice(0, n)'],
['takeRight','Array#slice(-n)'],
['tail','Array#slice(1)'],
]).map(([property,alternative])=>({
object:'_',
property,
message:`Use ${alternative} instead.`,
})),
...[
'readdirSync',
'readFileSync',
'statSync',
'lstatSync',
'existsSync',
'pathExistsSync',
'realpathSync',
'mkdirSync',
'mkdirpSync',
'mkdirsSync',
'writeFileSync',
'writeJsonSync',
'outputFileSync',
'outputJsonSync',
'moveSync',
'copySync',
'copyFileSync',
'ensureFileSync',
'ensureDirSync',
'ensureLinkSync',
'ensureSymlinkSync',
'unlinkSync',
'removeSync',
'emptyDirSync',
].map((property)=>({
object:'fs',
property,
message:'Do not use sync fs methods.',
})),
],
'no-restricted-syntax':[
WARNING,
// Copied from airbnb, removed for...of statement, added export all
{
selector:'ForInStatement',
message:
'for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array.',
},
{
selector:'LabeledStatement',
message:
'Labels are a form of GOTO; using them makes code confusing and hard to maintain and understand.',
},
{
selector:'WithStatement',
message:
'`with` is disallowed in strict mode because it makes code impossible to predict and optimize.',
},
{
selector:'ExportAllDeclaration',
message:
"Export all does't work well if imported in ESM due to how they are transpiled, and they can also lead to unexpected exposure of internal methods.",
description:Submit a bug report to help us improve
labels: [bug, 'status:needs triage']
body:
- type:markdown
attributes:
value:|
## Please help us help you!
Before filing your issue, ask yourself:
- Is this clearly a Docusaurus defect?
- Do I have basic ideas about where it goes wrong? (For example, if there are stack traces, are they pointing to one file?)
- Could it be because of my own mistakes?
**TheGitHub issue tracker is not a support forum**. If you are not sure whether it could be your mistakes, ask in the [Discord server](https://discord.gg/docusaurus) or [GitHub discussions](https://github.com/facebook/docusaurus/discussions) first. The quickest way to verify whether it's a Docusaurus defect is through a **reproduction**, starting with a fresh installation and making changes until the bug is reproduced.
Make the bug obvious. Ideally, we should be able to understand it without running any code.
Bugs are fixed faster if you include:
- A repro repository to inspect the code
- An url to see the problem live (if possible)
Pro tip:create a reproducible demo of the bug with https://new.docusaurus.io.
- type:checkboxes
attributes:
label:Have you read the Contributing Guidelines on issues?
options:
- label:I have read the [Contributing Guidelines on issues](https://github.com/facebook/docusaurus/blob/main/CONTRIBUTING.md#issues).
required:true
- type:checkboxes
attributes:
label:Prerequisites
description:Please check the following items before creating a issue. This way we know you've done these steps first.
options:
- label:I'm using the latest version of Docusaurus.
required:true
- label:I have tried the `npm run clear` or `yarn clear` command.
- label:I have tried `rm -rf node_modules yarn.lock package-lock.json` and re-installing packages.
- label:I have tried creating a repro with https://new.docusaurus.io.
- label:I have read the console error message carefully (if applicable).
- type:textarea
attributes:
label:Description
description:A clear and concise description of what the bug is.
validations:
required:true
- type:input
attributes:
label:Reproducible demo
description:|
Paste the link to an example repo, including a `docusaurus.config.js`, and exact instructions to reproduce the issue. It can either be a playground link created from https://new.docusaurus.io, or a git repository.
> **What happens if you skip this step?** Someone will read your bug report, and maybe will be able to help you, but it’s unlikely that it will get much attention from the team. Eventually, the issue will likely get closed in favor of issues that have reproducible demos.
Please remember that:
- Issues without reproducible demos have a very low priority.
- The person fixing the bug would have to do that anyway. Please be respectful of their time.
- You might figure out the issues yourself as you work on extracting it.
Thanks for helping us help you!
- type:textarea
attributes:
label:Steps to reproduce
description:Write down the steps to reproduce the bug. You should start with a fresh installation, or your git repository linked above.
placeholder:|
1. Step 1...
2. Step 2...
3. Step 3...
validations:
required:true
- type:textarea
attributes:
label:Expected behavior
description:|
How did you expect your project to behave? It’s fine if you’re not sure your understanding is correct. Write down what you thought would happen.
placeholder:Write what you thought would happen.
validations:
required:true
- type:textarea
attributes:
label:Actual behavior
description:|
Did something go wrong? Is something broken, or not behaving as you expected?
Describe this section in detail, and attach screenshots if possible. Don't only say "it doesn't work"!
Please submit exhaustive and complete log messages (we also need the error stack-traces, not just the message).
> Please read error messages carefully:it often tells you exactly what you are doing wrong.
placeholder:Write what happened. Add full console log messages and screenshots, if applicable.
validations:
required:true
- type:textarea
attributes:
label:Your environment
description:Include as many relevant details about the environment you experienced the bug in.
value:|
- Public source code:
- Public site URL:
- Docusaurus version used:
- Environment name and version (e.g. Chrome 89, Node.js 16.4):
- Operating system and version (e.g. Ubuntu 20.04.2 LTS):
- type:checkboxes
attributes:
label:Self-service
description:|
If you feel like you could contribute to this issue, please check the box below. This would tell us and other people looking for contributions that someone's working on it.
If you do check this box, please send a pull request within 7 days so we can still delegate this to someone else.
about:The Canny board to send us feature requests, vote and measure the interest of users. Useful to submit a feature request when you have an idea but no concrete API design proposal.
- name:❓ Simple question - Discord chat
url:https://discord.gg/docusaurus
about:This issue tracker is not for technical support. Please use our Discord chat, and ask the community for help.
description:Report an issue related to documentation
labels: [documentation, 'status:needs triage']
body:
- type:markdown
attributes:
value:|
This template is strictly used for documentation requests, including:
- Documenting undocumented APIs;
- Elaborating on a particular topic;
- Updating external links;
- anything else that doesn't require touching the codebase itself.
If you followed the documentation but things don't work, take some time to consider if it's the documentation or the code that's wrong. In the latter, prefer using the "bug" template.
We seldom close documentation pull requests unmerged. If your documentation request is:
- Relevant to a significant proportion of Docusaurus users;
- Not about external tooling (e.g. deployment workflow. We have a "deployment" section but we have decided to keep it mostly as-is);
- Not documented elsewhere (or, if it is documented, the mention is in very undiscoverable places).
You may proceed directly to sending a pull request without filing this issue, and we can improve on your work.
If you think some of the requirements above are not met, or if you are not able to contribute yourself, the issue is still welcomed.
- type:checkboxes
attributes:
label:Have you read the Contributing Guidelines on issues?
options:
- label:I have read the [Contributing Guidelines on issues](https://github.com/facebook/docusaurus/blob/main/CONTRIBUTING.md#issues).
required:true
- type:textarea
attributes:
label:Description
description:A clear and concise description of what the issue is.
validations:
required:true
- type:checkboxes
attributes:
label:Self-service
description:|
If you feel like you could contribute to this issue, please check the box below. This would tell us and other people looking for contributions that someone's working on it.
If you do check this box, please send a pull request within 7 days so we can still delegate this to someone else.
options:
- label:I'd be willing to address this documentation request myself.
description:Submit a detailed feature request with a concrete proposal, including an exhaustive API / UI design
labels: [feature, 'status:needs triage']
body:
- type:markdown
attributes:
value:|
Important things:
- We expect you to submit a feature request including a real design (API / UI...), not just a basic idea.
- The design does not have to be perfect, we'll discuss it and fix it if needed.
- For a more "casual" feature request, consider using Canny instead: https://docusaurus.io/feature-requests.
- type:checkboxes
attributes:
label:Have you read the Contributing Guidelines on issues?
options:
- label:I have read the [Contributing Guidelines on issues](https://github.com/facebook/docusaurus/blob/main/CONTRIBUTING.md#issues).
required:true
- type:textarea
attributes:
label:Description
description:A clear and concise description of what the feature is.
validations:
required:true
- type:input
attributes:
label:Has this been requested on Canny?
description:Please post the [Canny](https://docusaurus.io/feature-requests) link, it is helpful to see how much interest there is for this feature.
- type:textarea
attributes:
label:Motivation
description:Please outline the motivation for the proposal and why it should be implemented. Has this been requested by a lot of users?
validations:
required:true
- type:textarea
attributes:
label:API design
description:|
Please describe how Docusaurus users will enable and configure this feature, and what it will look like.
Please explain in an exhaustive way what are the config/plugin options and their respective effects. For visual elements, please send us some screenshots/mockups of what it should look like. You can use https://excalidraw.com to create simple mockups.
> **What happens if you skip this step?** This issue may be closed without any in-depth discussion. Your feature request is just an idea for now, please use Canny for that:https://docusaurus.io/feature-requests.
- type:textarea
attributes:
label:Have you tried building it?
description:|
Please explain how you tried to build the feature by yourself, and how successful it was.
Docusaurus 2 has a plugin system and theming support. Quite often, this gives you the opportunity to build the feature you need by yourself.
We expect you to put your own work in this feature, particularly if it is not requested by a lot of users. If we see it in action on your own site, it is easier to understand its value, and how it should work.
If you can't build it yourself for technical reasons, please explain why. We are willing to help you, and eventually providing new APIs to make it possible.
> **What happens if you skip this step?** This issue may be closed without any in-depth discussion. Your feature request is just an idea for now, please use Canny for that:https://docusaurus.io/feature-requests.
- type:checkboxes
attributes:
label:Self-service
description:|
If you answered the question above as "no" because you feel like you could contribute directly to our repo, please check the box below. This would tell us and other people looking for contributions that someone's working on it.
If you do check this box, please send a pull request within 7 days after a maintainer's approval so we can still delegate this to someone else.
Note that for feature issues, we still require you to fully fill out this form and reach consensus with the maintainers on API design before rushing to implement it, so that you don't waste your time.
options:
- label:I'd be willing to contribute this feature to Docusaurus myself.
description:Propose a non-trivial change to Docusaurus
labels: [proposal, 'status:needs triage']
body:
- type:markdown
attributes:
value:|
Common reasons for proposals include:
- Altering the infrastructure (e.g. swapping Webpack out with other bundlers);
- Bumping a critical dependency's major version;
- A significant improvement to a CLI command;
- Significant refactor;
- ...
This is not for feature requests. If this involves new APIs or new behaviors, consider requesting the feature on https://docusaurus.io/feature-requests instead.
We give you maximum freedom to write an elaborated proposal illustrating why you think the change is beneficial for us, and what steps we should take to turn this into reality.
You should not use this to ditch the feature request or bug template; such action could make us identify the issue wrongly and close it without doing anything.
- type:checkboxes
attributes:
label:Have you read the Contributing Guidelines on issues?
options:
- label:I have read the [Contributing Guidelines on issues](https://github.com/facebook/docusaurus/blob/main/CONTRIBUTING.md#issues).
required:true
- type:textarea
attributes:
label:Motivation
description:A clear and concise description of what the proposal is.
validations:
required:true
- type:checkboxes
attributes:
label:Self-service
description:|
If you feel like you could contribute to this issue, please check the box below. This would tell us and other people looking for contributions that someone's working on it.
If you do check this box, please send a pull request within 7 days after a maintainer's approval so we can still delegate this to someone else.
Proposals usually involve significant code changes, so please reach consensus with the maintainers before rushing to implement it. This ensures that you don't waste your time and we don't waste ours reading the large diffs.
options:
- label:I'd be willing to do some initial work on this proposal myself.
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to Docusaurus here: https://github.com/facebook/docusaurus/blob/master/CONTRIBUTING.md
You can learn more about contributing to Docusaurus here: https://github.com/facebook/docusaurus/blob/main/CONTRIBUTING.md
Happy contributing!
-->
## Pre-flight checklist
- [ ] I have read the [Contributing Guidelines on pull requests](https://github.com/facebook/docusaurus/blob/main/CONTRIBUTING.md#pull-requests).
- [ ] **If this is a code change**: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
- [ ] **If this is a new API or substantial change**: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.
<!--
Please also remember to sign the CLA, although you can also sign it after submitting the PR. The CLA is required for us to merge your PR.
If this PR adds or changes functionality, please take some time to update the docs. You can also write docs after the API design is finalized and the code changes have been approved.
-->
## Motivation
(Write your motivation here.)
### Have you read the [Contributing Guidelines on pull requests](https://github.com/facebook/docusaurus/blob/master/CONTRIBUTING.md#pull-requests)?
(Write your answer here.)
<!-- Help us understand your motivation by explaining why you decided to make this change. Does this fix a bug? Does it close an issue? -->
## Test Plan
(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)
<!-- Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos! -->
## Related PRs
### Test links
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/docusaurus, and link to your PR here.)
<!--
🙏 Please add an exhaustive list of links relevant to this pull request.
⏱ This saves maintainers a lot of time during reviews.
- If you changed anything that's displayed on UI, please add a dogfooding page in website/_dogfooding to help us preview the effect. Those tests are deployed at https://docusaurus.io/tests
- If you changed documentation, please link to the new and updated documentation pages.
After submission, our Netlify bot will post a deploy preview link in comment, in the format of https://deploy-preview-<PR-NUMBER>--docusaurus-2.netlify.app/. Once available, please edit this section with links to the relevant deploy preview pages.
Please don't be afraid to change the main site's configuration as well! You can make use of your new feature on our site so we can preview its effects. We can decide if it should be kept in production before merging it.
<!-- If you haven't already, link to issues/PRs that are related to this change. This helps us develop the context and keep a rich repo history. If this PR is a continuation of a past PR's work, link to that PR. If the PR addresses part of the problem in a meta-issue, mention that issue. -->
[Docusaurus](https://docusaurus.io) is our way to hopefully help to create open source documentation easier. We currently have [multiple open source projects using it](https://docusaurus.io/showcase), with many more planned. If you're interested in contributing to Docusaurus, hopefully, this document makes the process for contributing clear.
[Docusaurus](https://docusaurus.io) is our way to hopefully help make open source documentation easier. We currently have [multiple open source projects using it](https://docusaurus.io/showcase), with many more planned. If you're interested in contributing to Docusaurus, hopefully, this document makes the process for contributing clear.
The [Open Source Guides](https://opensource.guide/) website has a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project. Contributors and people new to open source alike will find the following guides especially useful:
- [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
## [Code of Conduct](https://code.fb.com/codeofconduct)
## Code of Conduct
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read [the full text](https://code.fb.com/codeofconduct) so that you can understand what actions will and will not be tolerated.
@ -15,30 +15,17 @@ Facebook has adopted a Code of Conduct that we expect project participants to ad
There are many ways to contribute to Docusaurus, and many of them do not involve writing any code. Here's a few ideas to get started:
- Simply start using Docusaurus. Go through the [Getting Started](https://docusaurus.io/docs/installation) guide. Does everything work as expected? If not, we're always looking for improvements. Let us know by [opening an issue](#reporting-new-issues).
- Simply start using Docusaurus. Go through the [Getting Started](https://docusaurus.io/docs/installation) guide. Does everything work as expected? If not, we're always looking for improvements. Let us know by [opening an issue](#issues).
- Look through the [open issues](https://github.com/facebook/docusaurus/issues). Provide workarounds, ask for clarification, or suggest labels. Help [triage issues](#triaging-issues-and-pull-requests).
- If you find an issue you would like to fix, [open a pull request](#your-first-pull-request). Issues tagged as [_Good first issue_](https://github.com/facebook/docusaurus/labels/Good%20first%20issue) are a good place to get started.
- Read through the [Docusaurus docs](https://docusaurus.io/docs/installation). If you find anything that is confusing or can be improved, you can make edits by clicking "Edit" at the top of most docs.
- Take a look at the [features requested](https://github.com/facebook/docusaurus/labels/enhancement) by others in the community and consider opening a pull request if you see something you want to work on.
- If you find an issue you would like to fix, [open a pull request](#pull-requests). Issues tagged as [_Good first issue_](https://github.com/facebook/docusaurus/labels/Good%20first%20issue) are a good place to get started.
- Read through the [Docusaurus docs](https://docusaurus.io/docs/installation). If you find anything that is confusing or can be improved, you can click "Edit this page" at the bottom of most docs, which takes you to the GitHub interface to make and propose changes.
- Take a look at the [features requested](https://github.com/facebook/docusaurus/labels/feature) by others in the community and consider opening a pull request if you see something you want to work on.
Contributions are very welcome. If you think you need help planning your contribution, please ping us on Twitter at [@docusaurus](https://twitter.com/docusaurus) and let us know you are looking for a bit of help.
### Versioned Docs
If you only want to make content changes you just need to know about versioned docs.
- `website/docs` - The files in here are responsible for the "next" version at https://docusaurus.io/docs/next/installation.
- `website/versioned_docs/version-X.Y.Z` - These are the docs for the X.Y.Z version at https://docusaurus.io/docs/X.Y.Z/installation.
To make a fix to the published versions you must edit the corresponding markdown file in both folders. If you only made changes in `docs`, be sure to be viewing the `next` version to see the updates (ensure there's `next` in the URL).
> Do not edit the auto-generated files within `versioned_docs/` or `versioned_sidebars/` unless you are sure it is necessary. For example, information about new features should not be documented in versioned docs. Edits made to older versions will not be propagated to newer versions of the docs.
### Join our Discord Channel
We have `#docusaurus-dev` on [Discord](https://discord.gg/docusaurus) to discuss all things Docusaurus development.
To participate in Docusaurus 2 dev, we have the [`#docusaurus-2-dev`](https://discord.gg/n8nQEAS) channel.
We have the [`#contributors`](https://discord.gg/6g6ASPA) channel on [Discord](https://discord.gg/docusaurus) to discuss all things about Docusaurus development. You can also be of great help by helping other users in the [`#help-and-questions`](https://discord.gg/fwbcrQ3dHR) channel.
### Triaging Issues and Pull Requests
@ -53,55 +40,84 @@ One great way you can contribute to the project without writing any code is to h
Docusaurus uses [GitHub](https://github.com/facebook/docusaurus) as its source of truth. The core team will be working directly there. All changes will be public from the beginning.
When a change made on GitHub is approved, it will be checked by our continuous integration system, CircleCI.
All pull requests will be checked by the continuous integration system, GitHub actions. There are unit tests, end-to-end tests, performance tests, style tests, and much more.
### Branch Organization
Docusaurus has one primary branches `master` and we use feature branches with deploy previews to deliver new features with pull requests.
Docusaurus has one primary branch`main` and we use feature branches with deploy previews to deliver new features with pull requests.
## Bugs
## Issues
We use [GitHub Issues](https://github.com/facebook/docusaurus/issues) for our public bugs. If you would like to report a problem, take a look around and see if someone already opened an issue about it. If you are certain this is a new, unreported bug, you can submit a [bug report](#reporting-new-issues).
When [opening a new issue](https://github.com/facebook/docusaurus/issues/new/choose), always make sure to fill out the issue template. **This step is very important!** Not doing so may result in your issue not being managed in a timely fashion. Don't take this personally if this happens, and feel free to open a new issue once you've gathered all the information required by the template.
If you have questions about using Docusaurus, contact the Docusaurus Twitter account at [@docusaurus](https://twitter.com/docusaurus), and we will do our best to answer your questions.
**Please don't use the GitHub issue tracker for questions.** If you have questions about using Docusaurus, use any of our [support channels](https://docusaurus.io/community/support), and we will do our best to answer your questions.
You can also file issues as [feature requests or enhancements](https://github.com/facebook/docusaurus/labels/feature%20request). If you see anything you'd like to be implemented, create an issue with [feature template](https://raw.githubusercontent.com/facebook/docusaurus/master/.github/ISSUE_TEMPLATE/feature.md)
### Bugs
## Reporting New Issues
When [opening a new issue](https://github.com/facebook/docusaurus/issues/new/choose), always make sure to fill out the issue template. **This step is very important!** Not doing so may result in your issue not managed in a timely fashion. Don't take this personally if this happens, and feel free to open a new issue once you've gathered all the information required by the template.
We use [GitHub Issues](https://github.com/facebook/docusaurus/issues) for our public bugs. If you would like to report a problem, take a look around and see if someone already opened an issue about it. If you are certain this is a new, unreported bug, you can submit a [bug report](https://github.com/facebook/docusaurus/issues/new?assignees=&labels=bug%2Cstatus%3A+needs+triage&template=bug.yml).
- **One issue, one bug:** Please report a single bug per issue.
- **Provide reproduction steps:** List all the steps necessary to reproduce the issue. The person reading your bug report should be able to follow these steps to reproduce your issue with minimal effort.
If you're only fixing a bug, it's fine to submit a pull request right away but we still recommend filing an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue.
### Security Bugs
Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe disclosure of security bugs. With that in mind, please do not file public issues; go through the process outlined on that page.
## Installation
### Feature requests
1. Ensure you have [Yarn](https://yarnpkg.com/) installed.
1. After cloning the repository, run `yarn install` in the root of the repository.
1. To start a development server:
If you would like to request a new feature or enhancement but are not yet thinking about opening a pull request, you can file an issue with the [feature template](https://github.com/facebook/docusaurus/issues/new?assignees=&labels=feature%2Cstatus%3A+needs+triage&template=feature.yml) in the form of an **elaborated RFC**. Alternatively, you can use the [Canny board](https://docusaurus.io/feature-requests) for more casual feature requests and gain enough traction before proposing an RFC.
- For Docusaurus 1 development, run `yarn start:v1`
- For Docusaurus 2 development, run `yarn start`
### Proposals
## Online one-click setup for contributing
If you intend to make any non-trivial changes to existing implementations, we recommend filing an issue with the [proposal template](https://github.com/facebook/docusaurus/issues/new?assignees=&labels=proposal%2Cstatus%3A+needs+triage&template=proposal.yml). This lets us reach an agreement on your proposal before you put significant effort into it. These types of issues should be rare.
You can use Gitpod (a free, online, VS Code-like IDE) for contributing. With a single click it will launch a workspace (for Docusaurus 2) and automatically:
### Claiming issues
We have a list of [beginner-friendly issues](https://github.com/facebook/docusaurus/labels/good%20first%20issue) to help you get your feet wet in the Docusaurus codebase and familiar with our contribution process. This is a great place to get started.
Apart from the `good first issue`, the following labels are also worth looking at:
- [`help wanted`](https://github.com/facebook/docusaurus/labels/help%20wanted): if you have specific knowledge in one domain, working on these issues can make your expertise shine.
- [`status: accepting pr`](https://github.com/facebook/docusaurus/labels/status%3A%20accepting%20pr): community contributors can feel free to claim any of these.
If you want to work on any of these issues, just drop a message saying "I'd like to work on this", and we will assign the issue to you and update the issue's status as "claimed". **You are expected to send a pull request within seven days** after that, so we can still delegate the issue to someone else if you are unavailable.
Alternatively, when opening an issue, you can also click the "self service" checkbox to indicate that you'd like to work on the issue yourself, which will also make us see the issue as "claimed".
## Development
### Online one-click setup for contributing
You can use Gitpod (a free, online, VS Code-like IDE) for contributing. With a single click, it will launch a workspace (for Docusaurus 2) and automatically:
- clone the docusaurus repo.
- install the dependencies.
- run `yarn run start`
- run `yarn start`
So that you can start contributing straight away.
[](https://gitpod.io/#https://github.com/facebook/docusaurus)
## Pull Requests
You can also try using the new [github.dev](https://github.dev/facebook/docusaurus) feature. While you are browsing any file, changing the domain name from `github.com` to `github.dev` will turn your browser into an online editor. You can start making changes and send pull requests right away.
### Your First Pull Request
### Installation
1. Ensure you have [Yarn](https://yarnpkg.com/) installed.
2. After cloning the repository, run `yarn install` in the root of the repository. This will install all dependencies as well as build all local packages.
3. To start a development server, run `yarn workspace website start`.
### Code Conventions
- **Most important: Look around.** Match the style you see used in the rest of the project. This includes formatting, naming files, naming things in code, naming things in documentation, etc.
- "Attractive"
- We do have Prettier (a formatter) and ESLint (a syntax linter) to catch most stylistic problems. If you are working locally, they should automatically fix some issues during every git commit.
- **For documentation**: Do not wrap lines at 80 characters - configure your editor to soft-wrap when editing documentation.
Don't worry too much about styles in general—the maintainers will help you fix them as they review your code.
## Pull Requests
So you have decided to contribute code back to upstream by opening a pull request. You've invested a good chunk of time, and we appreciate it. We will do our best to work with you and get the PR looked at.
@ -109,40 +125,96 @@ Working on your first Pull Request? You can learn how from this free video serie
[**How to Contribute to an Open Source Project on GitHub**](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github)
We have a list of [beginner friendly issues](https://github.com/facebook/docusaurus/labels/good%20first%20issue) to help you get your feet wet in the Docusaurus codebase and familiar with our contribution process. This is a great place to get started.
### Proposing a Change
If you would like to request a new feature or enhancement but are not yet thinking about opening a pull request, you can also file an issue with the [feature template](https://github.com/facebook/docusaurus/issues/new?template=feature.md).
If you intend to change the public API (e.g., something in `siteConfig.js`) or make any non-trivial changes to the implementation, we recommend filing an issue with the [proposal template](https://github.com/facebook/docusaurus/issues/new?template=proposal.md) and including `[Proposal]` in the title. This lets us reach an agreement on your proposal before you put significant effort into it. These types of issues should be rare.
If you're only fixing a bug, it's fine to submit a pull request right away but we still recommend filing an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue.
### Sending a Pull Request
Small pull requests are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it. It is recommended to follow this [commit message style](#semantic-commit-messages).
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`.
1. Add the copyright notice to the top of any code new files you've added.
1. 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)!
1. Make sure your code lints (`yarn prettier && yarn lint`).
1. Make sure your Jest tests pass (`yarn test`).
1. If you haven't already, [sign the CLA](https://code.facebook.com/cla).
1. **Keep your PR small.** Small pull requests (~300 lines of diff) are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
2. **Use descriptive titles.** It is recommended to follow this [commit message style](#semantic-commit-messages).
3. **Test your changes.** Describe your [**test plan**](#test-plan) in your pull request description.
4. **CLA.** If you haven't already, [sign the CLA](https://code.facebook.com/cla).
All pull requests should be opened against the `master` branch.
All pull requests should be opened against the `main` branch.
#### Test Plan
We have a lot of integration systems that run automated tests to guard against mistakes. The maintainers will also review your code and fix obvious issues for you. These systems' duty is to make you worry as little about the chores as possible. Your code contributions are more important than sticking to any procedures, although completing the checklist will surely save everyone's time.
A good test plan has the exact commands you ran and their output, provides screenshots or videos if the pull request changes UI.
### Semantic Commit Messages
- If you've changed APIs, update the documentation.
See how a minor change to your commit message style can make you a better programmer.
If you need help testing your changes locally, you can check out the doc on doing [local third party testing](./admin/local-third-party-project-testing.md).
Format: `<type>(<scope>): <subject>`
#### Breaking Changes
`<scope>` is optional. If your change is specific to one/two packages, consider adding the scope. Scopes should be brief but recognizable, e.g. `content-docs`, `theme-classic`, `core`
The various types of commits:
- `feat`: a new API or behavior **for the end user**.
- `fix`: a bug fix **for the end user**.
- `docs`: a change to the website or other Markdown documents in our repo.
- `refactor`: a change to production code that leads to no behavior difference, e.g. splitting files, renaming internal variables, improving code style...
- `test`: adding missing tests, refactoring tests; no production code change.
- `chore`: upgrading dependencies, releasing new versions... Chores that are **regularly done** for maintenance purposes.
- `misc`: anything else that doesn't change production code, yet is not `test` or `chore`. e.g. updating GitHub actions workflow.
Do not get too stressed about PR titles, however. Your PR will be squash-merged and your commit to the `main` branch will get the title of your PR, so commits within a branch don't need to be semantically named. The maintainers will help you get the PR title right, and we also have a PR label system that doesn't equate with the commit message types. Your code is more important than conventions!
Example:
```
feat(core): allow overriding of webpack config
^--^^----^ ^------------^
| | |
| | +-> Summary in present tense. Use lower case not title case!
| |
| +-> The package(s) that this change affected.
|
+-------> Type: see above for the list we use.
```
### Versioned Docs
If you only want to make doc changes, you just need to be aware of versioned docs.
- `website/docs` - The files here are responsible for the "next" version at https://docusaurus.io/docs/next/installation.
- `website/versioned_docs/version-X.Y.Z` - These are the docs for the X.Y.Z version at https://docusaurus.io/docs/X.Y.Z/installation.
Do not edit the auto-generated files within `versioned_docs/` or `versioned_sidebars/` unless you are sure it is necessary. For example, information about new features should not be documented in versioned docs. Edits made to older versions will not be propagated to newer versions of the docs.
### Test Plan
A good test plan has the exact commands you ran and their output and provides screenshots or videos if the pull request changes UI. If you've changed APIs, update the documentation.
Tests are integrated into our continuous integration system, so you don't always need to run local tests. However, for significant code changes, it saves both your and the maintainers' time if you can do exhaustive tests locally first to make sure your PR is in good shape. There are many types of tests:
- **Build and typecheck.** We use TypeScript in our codebase, which can make sure your code is consistent and catches some obvious mistakes early.
- **Unit tests.** We use [Jest](https://jestjs.io/) for unit tests of API endpoints' behavior. You can run `yarn test` in the root directory to run all tests, or `yarn test path/to/your/file.test.ts` to run a specific test.
- **Dogfooding.** Our website itself covers all kinds of potential configuration cases and we even have a dedicated [tests area](https://docusaurus.io/tests). Don't be afraid to update our website's configuration in your PR—it can help the maintainers preview the effects. We can decide if the website change should be kept when merging and deploying for production.
- **E2E tests.** You can simulate the distribution and installation of the code with your fresh changes. If you need help testing your changes locally, you can check out the doc on doing [local third-party testing](https://github.com/facebook/docusaurus/blob/main/admin/local-third-party-project-testing.md).
### Licensing
By contributing to Docusaurus, you agree that your contributions will be licensed under its MIT license. Copy and paste this to the top of your new file(s):
```js
/**
* Copyright (c) Facebook, Inc. and its affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*/
```
This is also auto-fixable with the `header/header` ESLint rule.
### Contributor License Agreement (CLA)
In order to accept your pull request, we need you to submit a CLA. You only need to do this once, so if you've done this for another Facebook open source project, you're good to go. If you are submitting a pull request for the first time, the Facebook GitHub Bot will reply with a link to the CLA form. You may also [complete your CLA here](https://code.facebook.com/cla).
After you have signed the CLA, the CLA bot would automatically update the PR status. There's no need to open a new PR.
**CLAs are required for us to merge your pull request.** While we value your effort and are willing to wait for you to come back and address the reviews in case you are unavailable after sending the pull request, pull requests that are ready to merge but have CLA missing and no response from the author **will be closed within two weeks of opening**. If you have further questions about the CLA, please stay in touch with us.
If it happens that you were unavailable and your PR gets closed, feel free to reopen once it's ready! We are still happy to review it, help you complete it, and eventually merge it.
### Breaking Changes
When adding a new breaking change, follow this template in your pull request:
@ -155,75 +227,6 @@ When adding a new breaking change, follow this template in your pull request:
- **Severity (number of people affected x effort)**:
```
#### Copyright Header for Source Code
Copy and paste this to the top of your new file(s):
```js
/**
* Copyright (c) Facebook, Inc. and its affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*/
```
#### Contributor License Agreement (CLA)
In order to accept your pull request, we need you to submit a CLA. You only need to do this once, so if you've done this for another Facebook open source project, you're good to go. If you are submitting a pull request for the first time, the Facebook GitHub Bot will reply with a link to the CLA form. You may also [complete your CLA here](https://code.facebook.com/cla).
### What Happens Next?
The core Docusaurus team will be monitoring for pull requests. Do help us by keeping pull requests consistent by following the guidelines above.
## Style Guide
[Prettier](https://prettier.io) will catch most styling issues that may exist in your code. You can check the status of your code styling by simply running `yarn prettier`.
However, there are still some styles that Prettier cannot pick up.
## Semantic Commit Messages
See how a minor change to your commit message style can make you a better programmer.
Format: `<type>(<scope>): <subject>`
`<scope>` is optional
## Example
```
feat: allow overriding of webpack config
^--^ ^------------^
| |
| +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.
```
The various types of commits:
- `feat`: (new feature for the user, not a new feature for build script)
- `fix`: (bug fix for the user, not a fix to a build script)
- `docs`: (changes to the documentation)
- `style`: (formatting, missing semi colons, etc; no production code change)
- `refactor`: (refactoring production code, eg. renaming a variable)
- `test`: (adding missing tests, refactoring tests; no production code change)
- `chore`: (updating grunt tasks etc; no production code change)
Use lower case not title case!
### Code Conventions
#### General
- **Most important: Look around.** Match the style you see used in the rest of the project. This includes formatting, naming files, naming things in code, naming things in documentation.
- "Attractive"
### Documentation
- Do not wrap lines at 80 characters - configure your editor to soft-wrap when editing documentation.
## License
By contributing to Docusaurus, you agree that your contributions will be licensed under its MIT license.
The core Docusaurus team will be monitoring pull requests. Do help us by keeping pull requests consistent by following the guidelines above.
<ahref="https://github.com/facebook/jest"><imgsrc="https://img.shields.io/badge/tested_with-jest-99424f.svg"alt="Tested with Jest"></a>
<ahref="https://argos-ci.com"target="_blank"rel="noreferrer noopener"aria-label="Covered by Argos"><imgsrc="https://argos-ci.com/badge.svg"alt="Covered by Argos"width="133"height="20"/></a>
<ahref="https://vercel.com/new/clone?repository-url=https%3A%2F%2Fgithub.com%2Ffacebook%2Fdocusaurus%2Ftree%2Fmain%2Fexamples%2Fclassic&project-name=my-docusaurus-site&repo-name=my-docusaurus-site"><imgsrc="https://vercel.com/button"alt="Deploy with Vercel"/></a>
<ahref="https://app.netlify.com/start/deploy?repository=https://github.com/slorber/docusaurus-starter"><imgsrc="https://www.netlify.com/img/deploy/button.svg"alt="Deploy to Netlify"></a>
</p>
## DOCUSAURUS-V1 BRANCH
Important: this is the archive branch containing the Docusaurus v1 code.
It also contains Docusaurus v2, because when we created the branch, both v1 and v2 lived on master.
As v1 is not active anymore, we didn't do the cleanup of this branch.
---
> **We are working hard on Docusaurus v2. If you are new to Docusaurus, try using the new version instead of v1. See the [Docusaurus v2 website](https://docusaurus.io/) for more details.**
> Docusaurus v1 doc is available at [v1.docusaurus.io](https://v1.docusaurus.io)
## Introduction
Docusaurus is a project for building, deploying, and maintaining open source project websites easily.
**Tip**: use **[new.docusaurus.io](https://new.docusaurus.io)** to test Docusaurus immediately in CodeSandbox.
Short on time? Check out our [5-minute tutorial ⏱️](https://tutorial.docusaurus.io)!
**Tip**: use **[docusaurus.new](https://docusaurus.new)** to test Docusaurus immediately in a playground.
- **Simple to Start**
@ -54,17 +49,13 @@ Docusaurus is a project for building, deploying, and maintaining open source pro
[Read the docs](https://docusaurus.io/docs/installation) for any further information.
## Contributing
@ -76,7 +67,7 @@ Facebook has adopted a Code of Conduct that we expect project participants to ad
### Contributing guide
Read our [contributing guide](https://github.com/facebook/docusaurus/blob/master/CONTRIBUTING.md) to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes to Docusaurus.
Read our [contributing guide](https://github.com/facebook/docusaurus/blob/main/CONTRIBUTING.md) to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes to Docusaurus.
### Beginner-friendly bugs
@ -86,9 +77,9 @@ To help you get your feet wet and get you familiar with our contribution process
We have a few channels for contact:
- [Discord](https://discord.gg/docusaurus) with two text channels:
- `#docusaurus-users` for those using Docusaurus.
- `#docusaurus-dev` for those wanting to contribute to the Docusaurus core.
- [Discord](https://discord.gg/docusaurus):
- `#general` for those using Docusaurus.
- `#contributors` for those wanting to contribute to the Docusaurus core.
- [@docusaurus](https://twitter.com/docusaurus) on Twitter
Docusaurus uses [Remarkable](https://github.com/jonschlinkert/remarkable) to convert plain markdown text into HTML. This document covers how one may extend Remarkable to provide custom functionality. While the document focuses on extending Remarkable in implementation, the theory should apply in general to any markdown parser.
## Why extend Remarkable?
Users of GitHub Pages have come to expect certain features provided by GitHub Flavored Markdown. One such example would be heading anchors, where every sub-header has an associated anchor that matches the heading text. This makes it possible to link to a specific section in a document by passing a fragment that matches the heading. For example, to link to this very section, you may create a link like so:
```md
[Link to this section](#why-extend-remarkable)
```
## A Brief Overview of How A Markdown Parser/Renderer Works
This is a summary of the basic concepts you'll need to understand in order to extend Remarkable, based on the [Remarkable docs](https://github.com/jonschlinkert/remarkable/tree/master/docs) as well as our own experience extending Remarkable to support GFM-style heading anchors.
As the heading here implies, there's two main parts to how a markdown parser works: the parsing phase, and the rendering phase. During the parsing phase, a plain markdown document is parsed into a set of tokens that describe its structure. These tokens are then used by the renderer to output the actual HTML contents.
### Parsing Markdown into Tokens
Let's talk a bit more about what is done as part of the parsing stage. The result of this stage is a tree made up of tokens. There's three types of tokens: inline, block, and core.
#### Inline tokens
Inline tokens are tokens that have text as a child. They are leaf nodes, and do not support having additional tokens within. An example of this might be `_emphasized text_`, which might be represented as a token of type `em` with contents of `emphasized text`.
#### Block tokens
A block token is a bit more complex. It may wrap one or more tokens, and can span more than one line of text. An example of this is the heading token:
```md
### Hi there
```
The plain markdown text above would be parsed into three tokens:
- `heading_open`: Marks the beginning of the heading. May have additional props, such as `hLevel: 3` (heading level) in this case.
- `text`: Plain text token, with a value of "Hi there".
- `heading_close`: Marks the end of the heading. In this case, it would also have a `hLevel: 3` prop.
This is a basic example, because it contains a `text` token within the opening and closing tags. A common block encountered in markdown is the paragraph, which might be tokenized into a series of tokens such as `paragraph_open`, one or more `text` tokens, `link` tokens (if links are present within the text, for example), and, eventually, a `paragraph_close` token.
#### Core tokens
These are outside of the initial scope of this article for now. Core tokens may be [reference-style links](https://github.github.com/gfm/#link-reference-definitions), which can appear anywhere in a markdown document.
### Rendering Tokens into HTML
After we have parsed everything into tokens, we go to the rendering phase. This is where we convert our `heading_open`, `text`, and `heading_close` tokens from earlier into `<h3>Hi there</h3>`. This should be self-explanatory.
## Creating a Remarkable Extension
Now that you have a better idea of how parsing/rendering works, we can proceed to create an extension that renders heading anchors. First we need to determine if we need to extend the parser, or the renderer. In this case, we're only interested in changing how a heading is rendered to HTML, so we'll just need to override the heading renderers.
The default heading renderers may look like this (you can refer to the Remarkable source code here):
```js
md.renderer.rules.heading_open = function (tokens, idx /*, options, env */) {
return '<h'+tokens[idx].hLevel+'>';
};
md.renderer.rules.heading_close = function (tokens, idx /*, options, env */) {
return '</h' + tokens[idx].hLevel + '>\n';
};
```
That's pretty straightforward: whenever these tokens are found, we render a `<hN>` or `</hN>` HTML tag, where N is the `hLevel` for this heading. That would result in `<h3>Hi there</h3>` being output. But what we want is something closer to this:
```html
<h3>
<aclass="anchor"id="hi-there"></a>Hi there
<aclass="hash-link"href="#hi-there">#</a>
</h3>
```
In that case, we need to override our heading rules like so:
```js
md.renderer.rules.heading_open = function (tokens, idx /*, options, env */) {
return (
'<h'+
tokens[idx].hLevel +
'>' +
'<aclass="anchor"id="'+
toSlug(tokens[idx + 1].content) +
'"></a>'
);
};
md.renderer.rules.heading_close = function (tokens, idx /*, options, env */) {
return (
' <aclass="hash-link"href="#'+
toSlug(tokens[idx - 1].content) +
'">#</a>' +
'</h' +
tokens[idx].hLevel +
'>\n'
);
};
```
Note that we are referring to `tokens[idx+1]` and `tokens[idx-1]` at various points in the code. In the case of `idx+1` in `heading_open`, it refers to the next token after `heading_open`, which is a `text` inline token. Same for `heading_close`, where we get the same `text` token by grabbing the preceding token. That's because we make a reasonable assumption that the markdown parser has generated three tokens for each of our headers as covered above.
### Using the Extension
We now need to tell Remarkable to use our extension. We can wrap our rules in a function called `anchors`:
```js
function anchors(md) {
md.renderer.rules.heading_open = function (tokens, idx /*, options, env */) {
return (
'<h'+
tokens[idx].hLevel +
'>' +
'<aclass="anchor"id="'+
toSlug(tokens[idx + 1].content) +
'"></a>'
);
};
md.renderer.rules.heading_close = function (tokens, idx /*, options, env */) {
return (
' <aclass="hash-link"href="#'+
toSlug(tokens[idx - 1].content) +
'">#</a>' +
'</h' +
tokens[idx].hLevel +
'>\n'
);
};
}
```
We can now tell Remarkable to load this function as a plugin (`md` is our instance of Remarkable):
```js
this.md.use(anchors);
```
### Future Work
A more advanced extension might add additional parser rules. These rules may add support for new markdown syntax not covered by Remarkable. Say, for example, a custom syntax to embed video when a tag like `@video` is found can be supported by generating a new type of token, that is later used by the renderer to output the necessary `<embed>` HTML tags. This is left as an exercise to the reader for now.
Sometimes you want to test the latest version of Docusaurus on a third-party project via `npm` or `yarn` without having to publish it to npm itself. For example, you may want to use the latest code in `master`.
Sometimes you want to test the latest version of Docusaurus on a third-party project via `npm` or `yarn` without having to publish it to npm itself. For example, you may want to use the latest code in `main`.
> If you want to use Docusaurus to test Docusaurus, see the [testing changes on Docusaurus itself doc](./testing-changes-on-Docusaurus-itself.md)
@ -6,125 +6,78 @@ There are two reasonable ways to use a local version of the Docusaurus npm packa
## Install from a local Docusaurus repo
> If you want to use the docusaurus-init script for testing, you will have to update the `initialize.js` file to point to the local Docusaurus repo instead of installing it from the npm server. In some ways, it is just easier to do the manual steps.
### Install in an existing project
### Install the package from the Docusaurus repo
```bash
cd /path/to/testing_project
mkdir website # if this does not exist already
cd website
```
If you do not have a `package.json` file in the `website` directory, create one with the following content:
Let's say you have an existing project with this snippet inside package.json:
```json
{
"scripts": {
"start": "docusaurus-start",
"build": "docusaurus-build",
"publish-gh-pages": "docusaurus-publish",
"examples": "docusaurus-examples"
"dependencies": {
"@docusaurus/core": "^2.0.0-beta.8",
"@docusaurus/preset-classic": "^2.0.0-beta.8"
}
}
```
Then:
Now, you have made changes to @docusaurus/core (this lives in packages/docusaurus) and would like to test the changes. In the local docusaurus repo, run `yarn install`. This will also build the local docusaurus packages and install them within the repo itself:
```sh
# Path to your Docusaurus clone
npm install ../../path/to/docusaurus/
cd /path/to/local/docusaurus
# can use yarn build:packages if dependencies have not been modified
yarn install
```
### Clowntown!
Now, we have a bit of clowntown here in the way symlinks are handled. The above `npm install`, creates a `node_modules` directory with a symlink in it. And errors will result if you try to access the local site after starting the server (as you do below). You will get something like this error:
```
ReferenceError: Unknown plugin "transform-class-properties" specified in "base" at 1, attempted to resolve relative to "/Users/joelm/dev/testing-local-Docusaurus-changes-site/website/core"
If you make further changes to the local docusaurus repo, run `yarn install` inside the existing project so that the changes will be applied.
```bash
./node_modules/.bin/docusaurus-examples # or whatever you want to test, if anything
./node_modules/.bin/docusaurus-start
```
Note that:
- The format is `scoped-package-name@local/path/to/specific/package/directory`.
- The last component of the supplied path cannot be a symbolic link, it has to be the package directory itself.
- If you supplied the wrong directory name, `yarn add` may not complain, but `yarn build` and `yarn start` will fail. To avoid this, check `package.json` inside the package directory to make sure you have the correct path.
- You cannot use `npm install` instead of `yarn add` for this purpose.
- `yarn link` is very likely to fail with react, unless you also manually link react. See https://github.com/facebook/react/issues/14257.
## Use Verdaccio
Verdaccio is a good local npm server that you can use to test your packages.
### Install verdaccio
We have a script `test:build:website` that starts a docker with verdaccio, publishes the packages, and initializes a new website in the parent directory. Alternatively, to install a package in the existing project, after you have started the verdaccio service, run
```bash
npm install --global verdaccio
npm_config_registry="http://localhost:4873" yarn install @docusaurus/core@"2.0.0-beta.8.NEW" # The version should be the latest
```
### Publish to verdaccio
You can refer to [the implementation](./scripts/test-release.sh) for more details.
When you are ready to test the code that could make up the next version of your package, you can publish locally to verdaccio
Run verdaccio in a **separate terminal window**:
If you don't have docker, you can still invoke the CLI manually to start the service.
```bash
verdaccio
```
In another terminal window, get ready to publish your local npm package:
```bash
# Your clone of Docusaurus
cd /path/to/docusaurus/
# use anything for user, password, email
# You should only have to do this once as long as you keep verdaccio installed
npm adduser --registry http://localhost:4873
npm publish --registry http://localhost:4873
```
You can navigate to localhost:4873 and you can see that your package was published. You can also see it showing you the steps you ran above as well.
### Install the local npm package and test
Now install the package in the repo you want to test Docusaurus on.
```bash
cd /path/to/testing_project/
mkdir website # if this does not exist already
cd website
```
If you do not have a `package.json` file in the `website` directory, create one with the following content:
```json
{
"scripts": {
"start": "docusaurus-start",
"build": "docusaurus-build",
"publish-gh-pages": "docusaurus-publish",
"examples": "docusaurus-examples"
}
}
```
Then:
```bash
npm install docusaurus --registry http://localhost:4873 # this may be slower than the normal npm registry
npm run examples # or whatever you want to test, if anything
The Netlify deployment (Joel can give access): https://app.netlify.com/sites/docusaurus-new/overview
See also the [Playground doc page](https://docusaurus.io/docs/playground)
Builds are stopped because we shouldn't need to redeploy the \_redirects file. You can just trigger a manual build if needed.
We use serverless functions because we want to persist the latest choice of the user in a cookie, so that it redirects directly to the preferred playground next time user visits this link. This is better to do it server-side with cookies and 302 redirects than with client redirects and localStorage.
Netlify deployment (Joel can give access): https://app.netlify.com/sites/docusaurus-new/overview
Builds are stopped because we shouldn't need to redeploy very often. You can just trigger a manual build if needed.
@ -10,7 +10,7 @@ Get access from the Docusaurus npm admins (@yangshun/@JoelMarcey).
You need publish access to **the main Docusaurus repository** (not a fork).
## NPM
## npm
Publishing will only work if you are logged into npm with an account with publishing rights to the package.
@ -30,54 +30,66 @@ If you're publishing new v2 versions, 2FA might get in the way as the pin might
### 1. Git setup
From the **master branch** (up to date, main repo, not a fork), create a new branch for the release.
From the **main branch** (up to date, main repo, not a fork), create a new branch for the release.
The branch name does not matter much, but you can use the `<your_username>/<version_to_release>` pattern.
```sh
# up to date master
git co master
# up to date main
git co main
git pull
# create a new release branch
git co -b <your_username>/<version_to_release>
```
### 2. Build and test the project
### 2. Clean, Build and test the project
Run `yarn install`
It should run `yarn build:packages` and build the project's packages.
To make sure that all packages will work correctly when they are published, we can initialize a new D2 skeleton website, and test that it can start/built.
Build all the packages from a clean state:
```sh
yarn test:build:v2
yarn clear
yarn install
```
This command will build all the packages that it will publish to the running private npm proxy registry, and then initialize a new website in the `test-website` directory. Now you can start the dev server and/or make a production built.
**Optional**: to make sure that all packages will work correctly when they are published, we can initialize a new D2 skeleton website, and test that it can start/built.
```sh
# This will build all the packages and publish them in a local Verdaccio npm registry
# and then initialize a new website in the `test-website` directory using those locally published packages
yarn test:build:website
# Now you can test the site in dev/prod mode
cd test-website
yarn start
yarn build # after manual testing in browser
yarn build
yarn serve
```
If there are no errors, you can start preparing for the new release.
**Note**: This step is also run by the CI on all pull requests ([see](https://github.com/facebook/docusaurus/pull/2954/checks?check_run_id=780871959))
This local test step is optional because it will be run by the CI on your release PR ([see](https://github.com/facebook/docusaurus/pull/2954/checks?check_run_id=780871959))
### 3. Update the v2 changelog
The changelog uses GitHub labels to classify each pull request. Use the GitHub interface to assign each newly merged pull request to a GitHub label starting with `tag:`, otherwise the PR won't appear in the changelog.
The changelog uses GitHub labels to classify each pull request. Use the GitHub interface to assign each newly merged pull request to a GitHub label starting with `pr:`, otherwise the PR won't appear in the changelog.
[Check tags of all recently merged Pull-Requests](https://github.com/facebook/docusaurus/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Amerged+)
Not all labels will appear in the changelog—some are designed not to. However, you should **always** label each PR, so that before release, we can do a quick scan and confirm no PR is accidentally left out. Here's a search query (pity that GH doesn't have wildcard queries yet):
The `tag:` label prefix is for PRs only. Other labels are not used by the changelog tool, and it's not necessary to assign such labels to issues, only PRs.
[Check tags of all recently merged Pull-Requests](https://github.com/facebook/docusaurus/pulls?q=is%3Apr+is%3Amerged+sort%3Aupdated-desc+-label%3A%22pr%3A+breaking+change%22%2C%22pr%3A+new+feature%22%2C%22pr%3A+bug+fix%22%2C%22pr%3A+performance%22%2C%22pr%3A+polish%22%2C%22pr%3A+documentation%22%2C%22pr%3A+maintenance%22%2C%22pr%3A+internal%22%2C%22pr%3A+dependencies%22%2C%22pr%3A+showcase%22)
Some general principles about the labeling process:
- "Will an average user be interested in this entry?" Items like "improve test coverage", "upgrade dependencies" can probably be left out (we have `pr: internal` and `pr: dependencies` for this). However, "pin GitHub actions to an SHA", "add visual testing infrastructure", etc., albeit internal, could be interesting to the user, and can be included in the "maintenance" section.
- "Will this change have tangible impact on the user?" A common case is when a PR implements a feature X, then there are immediately follow-up PRs that fix bugs or polish feature X. These follow-up PRs don't necessarily have to be in the changelog, and even if they alter the API, they are not breaking changes, because to an average user bumping their version, they will only see the new feature X as a whole. Make the entries atomic.
The `pr:` label prefix is for PRs only. Other labels are not used by the changelog tool, and it's not necessary to assign such labels to issues, only PRs.
Generate a GitHub auth token by going to https://github.com/settings/tokens (the only permission needed is `public_repo`). Save the token somewhere for future reference.
Fetch the tags from Github (lerna-changelog looks for commits since last tag by default):
Fetch the tags from GitHub (lerna-changelog looks for commits since last tag by default):
```sh
git fetch --tags
@ -96,26 +108,30 @@ Copy the generated contents and paste them in `CHANGELOG.md`.
It can happen that some accesses are not granted, as an admin might add you to the @docusaurusNPM organization, but you don't have access to the packages that are not in that organization.
It can happen that some accesses are not granted, as an admin might add you to the @docusaurusnpm organization, but you don't have access to the packages that are not in that organization.
Please **double-check your permissions on these 3 packages**, otherwise you'll publish a half-release and will have to release a new version.
Please **double-check your permissions on these packages**, otherwise you'll publish a half-release and will have to release a new version.
```
"docusaurus": "read-write",
"docusaurus-init": "read-write",
"create-docusaurus": "read-write",
"stylelint-copyright": "read-write"
```
@ -173,38 +187,38 @@ If all accesses are available, build all the necessary packages, and then run th
```sh
yarn build:packages
yarn lerna publish 2.0.0-alpha.68 --exact
yarn lerna publish --exact 2.0.0-beta.0
```
~~**Note**: The v1 packages will also be modified because it's part of the monorepo. It is not ideal but we will live with it for now.~~
This command does a few things:
- Modifies the versions of all the `package.json` in the repository to be `2.0.0-alpha.41` and creates a commit
- Creates a new Git tag `v2.0.0-alpha.41`
- Modifies the versions of all the `package.json` in the repository to be `2.0.0-beta.0` and creates a commit
- Creates a new Git tag `v2.0.0-beta.0`
- Pushes the new release commit on your branch, and add a git tag
You should receive many emails notifying you that a new version of the packages has been published.
If above command fail (network issue or whatever), you can try to recover with `yarn lerna publish from-package`: it will try to publish the packages that are missing on npm.
Now that the release is done, **merge the pull request**.
### 7. Create a release on GitHub
- Go to https://github.com/facebook/docusaurus/releases/new
- Under the "Tag version" field, look for the newly-created tag, which is `v2.0.0-alpha.41` in this case
- Under the "Tag version" field, look for the newly-created tag, which is `v2.0.0-beta.0` in this case
- Paste the CHANGELOG changes in the textarea below
- Hit the green "Publish release" button
- Profit! 💰
### 8. Update example projects (optional but desirable)
After a release, update the examples to keep them in sync with the latest release. This will ensure that CodeSandbox playground is able to use the new version at [new.docusaurus.io](https://new.docusaurus.io).
After a release, update the examples to keep them in sync with the latest release. This will ensure that playgrounds are able to use the new version at [docusaurus.new](https://docusaurus.new).
Create a separate branch/PR and run `yarn examples:generate`
### 9. Notify people about new release (optional but desirable)
After new release, it is cool to notify our users about this in the Discord chat (`docusaurus-users` channel) and write summaries on Twitter using the following templates.
After new release, it is cool to notify our users about this in the Discord chat (`#announcements` channel) and write summaries on Twitter using the following templates.
For Discord:
@ -234,98 +248,3 @@ NOTE: most likely this last item will be relevant for each new release, so do no
**TLDR**: you need to mark them as public, publish, and mark them back as private
v1 packages have been marked as `private: true` on purpose. This is because lerna will publish ALL (v1+v2) packages with the lerna-publish command.
Unfortunately it seems there is no way to tell it to ignore v1 packages while publishing v2.
During a long time, we published all these packages using the `@next` dist tag: `yarn lerna publish 2.0.0-alpha.41 --dist-tag next --exact`. It caused problems because v2 packages will then all need @next during npm/yarn installs, confusing some users (https://github.com/facebook/docusaurus/issues/3755).
We made the v1 packages private so that lerna publish won't publish them, so that we can publish v2 packages under latest dist tag, without creating v1 upgrades that people will be notified abut.
### Updated v1 release process
Process reworked by @slorber at `1.14.6`, it may not be perfect yet:
Suppose we are at `v1.14.5`, and want to release `v1.14.6`:
- Assign appropriate `tag: xyz` labels to merged PRs
- Be on master (up-to-date): `git co master && git pull`
- Create a new branch: `git co -b slorber/release-1.14.6`
- Get the changelog from last release: `git fetch --tags && GITHUB_AUTH=<myToken> yarn changelog --from=v1.14.5`
- Update [CHANGELOG-1.x.md](https://github.com/facebook/docusaurus/blob/master/CHANGELOG-1.x.md), but remove the v2-related items manually.
- Run `yarn install`
- Version the docs: `yarn workspace docusaurus-1-website docusaurus-version 1.14.6`
- Test the v1 website locally: `yarn start:v1` + `yarn build:v1`
- Run `git tag v1.14.6` (important: the tag is prefixed by **`v`**)
- Run `git push origin v1.14.6`
- Ensure you can run `yarn install` (it may fail and need to use v2 versions on the v1 packages...)
- Open a PR, and merge it
- Create the [new Github release](https://github.com/facebook/docusaurus/releases/new), paste the changelog
- The End
### Historical v1 release process
1. Bump version number in [`package.json`](https://github.com/facebook/docusaurus/blob/master/packages/docusaurus-1.x/package.json).
1. Update the [CHANGELOG-1.x.md](https://github.com/facebook/docusaurus/blob/master/CHANGELOG-1.x.md), including at the reference links at the bottom.
1. Do this always, but particularly important if there were any `package.json` changes in this release:
1. If there is no `node_modules` directory in you local Docusaurus version, run `yarn install` and `npm install`.
1. Run `yarn upgrade` to update `yarn.lock` and `npm update` to update `package-lock.json`.
1. From the `website-1.x` directory, run `npm run docusaurus-version x.x.x`, where x.x.x is the same version number you updated to in `package.json`.
1. Test your PR locally on a project that was created via [these instructions](https://github.com/facebook/docusaurus/blob/master/admin/local-third-party-project-testing.md).
1. Submit your PR
1. When your PR is merged, rebase to get the PR commit locally
1. Run `npm publish`
1. Tag the commit with the new version prefixed with a `v` (e.g. `v1.19.0`) and push the tag to `master`
1. Go to https://github.com/facebook/docusaurus/releases/new
1. Under the "Tag version" field, look for the newly-created tag
1. Paste the CHANGELOG changes in the textarea below
1. Hit the green "Publish release" button
1. Profit! 💰
### What version should you use?
The version number should generally increase by some factor than the current one. You can check current version by looking in `package.json`.
@ -8,18 +8,16 @@ It is straightforward to test your Docusaurus changes with Docusaurus.
```bash
cd /path/to/docusaurus-repo
npm install
yarn install
cd website
npm run start
yarn start
```
> If you look in the `website/package.json` file, you will notice that running `start` with `npm run` actually executes the local `start-server.js` file. This is how you know you are running with local code.
## Debugging Locally
### VS Code
Use the following code in VSCode to enable breakpoints. Please ensure you have a later version of node for non-legacy debugging.
Use the following code in VSCode to enable breakpoints. Please ensure you have a later version of node for non-legacy debugging.
```json
{
@ -43,4 +41,4 @@ Feel free to contribute debug instructions for other IDEs
### Observing changes
Now that the server is running, you can make changes to the core Docusaurus code and docs to see the effects on the Docusaurus site. LiveReload will reflect changes to the local site in your browser, usually running at http://localhost:3000.
Note that since most packages are built with TypeScript, you would need to compile them every time to see the effect. Alternatively, you can run `yarn watch` inside the package directory to start an incremental build. Now that the server is running, you can make changes to the core Docusaurus code and docs to see the effects on the Docusaurus site. LiveReload will reflect changes to the local site in your browser, usually running at http://localhost:3000.
We use [Argos CI](https://argos-ci.com) to detect visual regressions on Docusaurus.
This workspace can be run manually, but is generally run through the [Argos GitHub Action](../.github/workflows/argos.yml).
The workflow execute those following steps:
- Build the website locally with `yarn build:website:fast`
- Start the website server with `yarn serve:website` on [http://localhost:3000](http://localhost:3000)
- Take screenshots of all pages found in `sitemap.xml` with Playwright
- Upload all screenshots to [Argos CI](https://argos-ci.com)
This workflow runs for `main` and PR branches, and add a commit status to each PR with a visual diff that we can easily inspect.
---
Some additional capabilities:
- Use [./tests/screenshot.spec.ts](./tests/screenshot.spec.ts) to customize the screenshots we take, eventually filter out some useless sitemap pages like versioned docs
- Use [./tests/screenshot.css](./tests/screenshot.css) to hide flaky CSS elements: iframe, video, gif...
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
If you want add your own component, you can use the `swizzle` command. Check more at our [doc](https://docusaurus.io/docs/using-themes#swizzling-theme-components)
Some files were not shown because too many files have changed in this diff
Show More