Thanks for that you are interested in contributing to Rsdoctor. Before starting your contribution, please take a moment to read the following guidelines.
Fork this repository to your own GitHub account and then clone it to your local.
We recommend using Node.js 18. You can check your currently used Node.js version with the following command:
node -v
If you do not have Node.js installed in your current environment, you can use nvm or fnm to install it.
Here is an example of how to install the Node.js 18 LTS version via nvm:
# Install the LTS version of Node.js 18
nvm install 18 --lts
# Make the newly installed Node.js 18 as the default version
nvm alias default 18
# Switch to the newly installed Node.js 18
nvm use 18
Enable pnpm with corepack:
corepack enable
Install dependencies:
pnpm install
What this will do:
- Install all dependencies.
- Create symlinks between packages in the monorepo.
- Run the
prepare
script to build all packages, powered by nx.
Please make sure you have your email set up in <https://github.com/settings/emails>
. This will be needed later when you want to submit a pull request.
Check that your git client is already configured the email:
git config --list | grep email
Set the email to global config:
git config --global user.email "SOME_EMAIL@example.com"
Set the email for local repo:
git config user.email "SOME_EMAIL@example.com"
Once you have set up the local development environment in your forked repo, we can start development.
It is recommended to develop on a new branch, as it will make things easier later when you submit a pull request:
git checkout -b MY_BRANCH_NAME
Use nx build to build the package you want to change:
npx nx build @rsdoctor/core
Build all packages:
pnpm run build
When you make changes to the code and want to view the Rsdoctor
analysis report, you can execute build:analysis
in the examples/foo
project to see it:
pnpm run build:analysis
- Based on the Webpack project:
modern-minimal
andwebpack-minimal
. - Based on the Rspack project:
rspack-minimal
andrsbuild-minimal
.
If you've fixed a bug or added code that should be tested, then add some tests.
You can add unit test cases in the <PACKAGE_DIR>/tests
folder. The test syntax is based on Vitest.
Before submitting a pull request, it's important to make sure that the changes haven't introduced any regressions or bugs. You can run the unit tests for the project by executing the following command:
pnpm run test
Alternatively, you can run the unit tests of single package using the --filter
option:
pnpm run --filter @rsdoctor/some-package test
In addition to the unit tests, the Rsdoctor also includes end-to-end (E2E) tests, which checks the functionality of the application as a whole.
You can run the test:e2e
command to run the E2E tests:
pnpm run e2e
To help maintain consistency and readability of the codebase, we use Biome to lint the codes.
You can run the Linter by executing the following command:
pnpm run lint
For VS Code users, you can install the Biome VS Code extension to see lints while typing.
Currently Rsdoctor provides documentation in English and Chinese. If you can use Chinese, please update both documents at the same time. Otherwise, just update the English documentation.
You can find all the documentation in the document
folder:
root
└─ document
This website is built with Rspress, the document content can be written using markdown or mdx syntax. You can refer to the Rspress Website for detailed usage.
Commit your changes to your forked repo, and create a pull request.
The format of PR titles follow Conventional Commits.
An example:
feat(plugin-swc): Add `newOption` config
^ ^ ^
| | |__ Subject
| |_______ Scope
|____________ Type
You can input !bench
in the comment area of the PR to do benchmarking on rsdoctor
(you need to have Collaborator and above permissions).
You can focus on metrics related to build time and bundle size based on the comparison table output by comments to assist you in making relevant performance judgments and decisions.
Dependencies installation-related metrics base on publishing process, so the data is relatively lagging and is for reference only.
Repository maintainers can publish a new version of changed packages to npm.
- Checkout a new release branch, for example
release_v1.2.0
- Run changesets to bump changed packages and commit the changes.
- Create a pull request, the title should be
release: v1.2.0
. - Run the release action to publish packages to npm.
- Merge the release pull request to
main
. - Generate the release notes via GitHub, see Automatically generated release notes