We 💛 contributions! The rules for contributing to this org are few:
- Don't be a jerk
- Search issues before opening a new one
- Lint and run tests locally before submitting a PR
- Adhere to the code style the project has chosen
The jsx-email repository is a Monorepo that uses two primary tools: pnpm and Moon. pnpm is used for package management and workspace management. Moon is used as our task runner. Repo checks, tests, and builds should be run through Moon.
JSX email v3 requires Node.js v22.0.0 or newer and React v19.1.0 or newer.
If you're new to either pnpm or Moon you'll want to run the bootstrap.sh script first. It will install everything you'll need to get started, and bootstrap your environment:
$ ./shared/bootstrap.shNext we'll want to get dependencies installed, and get everything built. (Note: One of the benefits of Moon is that it uses intelligent caching to assert that dependencies are always up to date before running any command. We don't technically have to install dependencies first):
$ pnpm installThen build all the things:
$ moon repo:build.all --cache off- Use at least Node.js v22.0.0 or higher. NVM can be handy for switching between Node versions.
- Lint your changes via
moon run :lint. Fix any errors before committing. - Format your changes via
moon run :format. - Typecheck your changes via
moon run :typecheck. - Test your changes via
moon run :test. Only Pull Requests with passing tests will be accepted.
Any code change should be submitted as a pull request. Our guidelines for Pull Requests:
- Please fill in our template in its entirety. Please don't reformat it or modify it
- The description should explain what the code does and give steps to execute it
- The pull request should also contain tests
- Before submitting your Pull Request, please run
moon run :lint,moon run :format,moon run :typecheck, andmoon run :testin the root directory - If any checks fail for your Pull Request, please resolve them. Always feel free to ask for help if unable to resolve issues with checks
The bigger the pull request, the longer it will take to review and merge. Try to break down large pull requests in smaller chunks that are easier to review and merge.
It is also always helpful to have some context for your pull request. What was the purpose? Why does it matter to you? Does it resolve any known Github issues? Adding a line "resolves #<issue number>" (e.g. "resolves #23") to the description of your pull request or of a specific commit will automatically close this issue once the pull request is merged.