Skip to content

Latest commit

 

History

History
90 lines (65 loc) · 3.02 KB

CONTRIBUTING.md

File metadata and controls

90 lines (65 loc) · 3.02 KB

Development Setup

This project uses a monorepo setup that requires using Yarn because it relies on Yarn workspaces.

# Install all dependencies.
yarn install

# Serves MdPress' own docs with itself.
yarn dev

# Build MdPress' own docs with itself.
yarn build

# Execute all the test suites.
yarn test

# Clean dependencies.
yarn clean

# Useful when creating new a package.
yarn boot

Testing Setup

TODO

Core Packages

  • docs: Docs of MdPress (do not publish to npm).
  • mdpress: MdPress CLI.
  • packages
    • core: containing the Node.js API, the Plugin API, the Theme API, the Client SPA, etc.
    • markdown: internal Markdown compiler.
    • markdown-browser: internal Markdown compiler run in browser.
    • markdown-loader: internal Markdown loader.
    • plugin-active-header-links: a plugin for active sidebar heading links.
    • plugin-google-analytics: Google Analytics integration.
    • plugin-last-updated: implementation of "last updated" feature.
    • plugin-medium-zoom: medium-zoom integration.
    • plugin-nprogress: nprogress integration.
    • plugin-pwa: PWA plugin.
    • plugin-search: search plugin, providing the SearchBox component.
    • shared-utils: TypeScript utilities.
    • test-utils: test utilities.
    • theme-default: default theme.

Workflow

Issue

Use one of the issues templates when you open a issue. And please ask questions on the StackOverflow.

We'll close your issue if you delete the template or it contains questions.

Pull Requests

  • Create a feature branch from the default branch (master) and merge back against that branch.
  • It's OK to have multiple small commits as you work on the PR - GitHub automatically squashes them before merging.
  • Make sure tests pass.
  • If adding a new feature:
    • Add accompanying test case(s).
    • Provide a convincing reason to add this feature. Ideally, you should open a suggestion issue first and have it approved before working on it.
  • If fixing bug:
    • If you are resolving an open issue, add (fix #xxxx) (#xxxx being the issue ID) in your PR title for a better release log, e.g. chore(feat): implement SSR (fix #1234).
    • Provide a detailed description of the bug in the PR. Live demo preferred.
    • Add appropriate test coverage if applicable.

Code Specification

TODO

Commit Specification

Commit messages should follow the commit message convention so that changelogs can be automatically generated.

Check out the availalbe types at @commitlint/config-conventional. And the scopes should be one of the followings:

cli

# Core Packages/packages:
core
markdown
...
theme-xxx

Correct examples would be: fix($core): some message or feat: some message