Skip to main content

Running workflow

Once you have cloned your new docs repository, you will want to be able to know how to start previews, lint, build, and do all the necessary things in development.

Ideally, you would be somewhat acquainted with npm or yarn project workflows, as Docusaurus is a React-based project.

๐Ÿ‘จโ€๐Ÿ’ป Committing to your repoโ€‹

As part of running npm run prepare when initializing this repo, husky is installed to manage pre-commit hooks.

All commits are linted with commitlint with the conventional rules found in package.json.

lint-staged is used to run checks on certain staged Git files when committing. The commands that are run and on what files can be found in the package.json under the lint-staged key.

tip

It is recommended to use the command git commit only after staging files.

You should generally avoid git commit -m or similar commands which pass in the command-line or args like --allow-empty.

See example of git commit flow
gifExample

๐Ÿ“ฆ npm commands and scriptsโ€‹

Here is an exhaustive list of what each npm script does in the package.json.

caution

This is likely to change every so often and documentation may not be updated to reflect it always.

Please open an issue or PR to address it!

๐ŸŽ npm run startโ€‹

Run Docusaurus locally on port http://localhost:3000 to preview and supports automatic refresh when changes are made. This is usually used in development while making changes to Markdown or certain configuration files.

note

Not all changes made are supported by the automatic refresh and may require restarting the command.

๐Ÿ‘ท npm run buildโ€‹

Build Docusaurus for production into the ./build directory of the root folder of this project.

It is usually not necessary to do this in development and is usually only used by CI when building to be deployed.

caution

There is still an open issue regarding proper and stable CSS insertion ordering that may differ between npm run start and npm run build results.

Please see here for more details.

This is usually not an issue and can be mitigated with adding !important to CSS styles.

๐Ÿ“‘ npm run build:docsโ€‹

If you have chosen to use docusaurus-plugin-openapi-docs plugin for integrating OpenAPI to your docs, then this command will clean existing generated Markdown API docs and re-generate them.

This command is bundled into the npm run build command.

You can safely remove this script from the package.json if you are not using the plugin.

๐Ÿ–‹๏ธ npm run swizzleโ€‹

Swizzling allows more advanced customization of React Components in Docusaurus beyond simple CSS modifications.

โœˆ๏ธ npm run deployโ€‹

Built-in as part of Docusaurus for deploying project.

note

This command should not be necessary to use at all.

โŒฆ npm run clearโ€‹

If you are running into some issues with error when running npm run start, it is recommended to use the clear command to remove all generated assets, caches or build artifacts.

๐Ÿ“บ npm run serveโ€‹

This is to be run after the npm run build command as it will serve the files generated by the build output from the ./build directory for local viewing.

note

As npm run build is for production building or debugging production build issues, it should not be necessary to use npm runs serve except where those two scenarios require it.

๐ŸŒŽ npm run write-translationsโ€‹

Only needed where translations are to be added.

๐ŸŒŽ npm run write-heading-idsโ€‹

Only needed where translations are to be added.

โŒจ๏ธ npm run typecheckโ€‹

Typechecking with TypeScript and tsconfig.json.

โŒจ๏ธ npm run typecheck-stagedโ€‹

Typechecking staged-only files which is used by lint-staged when committing.

๐Ÿงผ npm run lintโ€‹

Combined command which includes spell check, JS/TS linting, and CSS linting.

๐Ÿงผ npm run lint:jsโ€‹

Lint JS/TS with ESLint.

๐Ÿงผ npm run lint:spellingโ€‹

Checking spelling with CSpell.

๐Ÿ“š Adding new words to the dictionaryโ€‹

It's possible that you will use a word in your content that is not known to the linter, and your build, or commit, will fail.

If this happens, take a look at project-words.txt in the root directory of your project; if the word that the linter caught is correctly spelled, and you wish it to pass the linter's test, add it to project-words.txt, save, add and commit those changes, and see if it passes.

๐Ÿงผ npm run lint:styleโ€‹

Lint CSS files with specific styling.

๐Ÿงผ npm run lint:fixโ€‹

Pass the --fix CLI argument to npm run lint:js to attempt to fix issues.

๐Ÿ–จ๏ธ npm run formatโ€‹

Run Prettier to format code before commit for consistency in the repo.

๐Ÿฅ— npm run prepareโ€‹

After npm install for the very first time, husky is installed for Git pre-commit hooks.