Contributing
Fork this repository, clone your fork and add this repository as the upstream remote.
You will need to have pnpm
installed so make sure you follow the installation instructions. At the time of writing the advised way to install is via npm i -g pnpm
.
You will also need to install git-lfs
which is used for managing large file storage. The installation is platform dependent so please follow the instructions outlined here.
If you already have a previous version of the repository checked out then make sure to clean your node_modules
by running the following command before installation.
Project Structure
The number of files in the root directory is deliberately as minimal as possible. This is achieved by moving all configuration files to the support/root
folder. Whenever you run pnpm install
these files are symlinked to the root directory.
.github
- TheGitHub
specific configuration for workflows, issue templates and pull request templates.docs
- The documentation for this project. This is also used by the docusaurus website.packages
- The packages provided by remirror. Within this folder there are top level packages likeremirror
andjest-remirror
and also scope packages within the@remirror/*
folder like@remirror/core
.support
- This is the package that provides the configuration files, the website, and many other folders. Each directory includes a readme file that explains it's functionality. Take a look.
Documentation
From the root directory use the following command to launch the documentation site.
Once the build completes (can take a minute the first time) navigate to http://localhost:3000 (or another port if that one is already being used).
The documentation is written using docusaurus and all files and dependencies are available in the /support/website
subdirectory. To add a new dependency, you will need to add it to /support/website/package.json
and not the top level package.json file. You can either do this by manually editing the /support/website/package.json
file or you use the following command.
Testing
Unit tests can be run with the following commands.
Always create your tests inside of a __tests__/
sub-folder.
Sometimes you will want to narrow down tests to run only a specific file or folder.
Once in watch mode you can also press p
and type out the file you want to focus on. Press enter to select the file.
For naming conventions, use the following.
- Unit tests:
*.spec.ts(x)
- Integration tests:
*.e2e.test.ts
within the/e2e
folder
Unit tests can be run limited to a specific package, e.g. for extension-bold
:
Using Git
I recommend that while working on your code you commit early and often. You won't be judged. All worked submitted in a pull request (see following section) will be squashed into one commit before merging (unless it makes sense to keep the commits as separate items).
remirror
has built in husky support for git hooks
- Before each commit (lint and test changed files)
- Before each push (lint, typecheck and test)
By default these checks are not run automatically. To enable automatic pre-commit and pre-push hooks use the following command:
To stop per-commit / per-push checks run:
Development
If you're modifying a package and import helpers from another packages in the monorepo, ensure that the other package is referenced in the referring package's package.json
file.
General
This project uses preconstruct
to manage builds. Each time the project is installed preconstruct dev
is run which automatically sets the dist folder with entry points mapping to the source files of the package. This is really useful for development and except for one exception when working on the playground is all you need.
Playground
Working on the playground needs an extra step. The code being injected into the iframe needs to be pre-compiled and updates will fail for you if using preconstruct dev
. The following command resolves this problem.
When run this builds all packages and then watch for changes to rebuild as necessary. One issue with running this command is that you will lose any meaningful type checking. If you run pnpm typecheck
and it fails with cryptic issues, it may be that you're still in the build state.
Pull Request (PR) Process
Once your work is complete you'll want to create a Pull Request to share all that goodness with the rest of us.
- Create a pull request using the github interface. The template will automatically populate for you.
- Add a description and reference the issue this pull request addresses where applicable. The description will be used as the body of the git commit message since all pull request are squashed down into one commit before merging.
- Tick off all relevant check boxes by placing an x between the square brackets i.e.
[ ]
to[x]
. - Please add a screenshot where the change is related to the user interface or design. It makes it so much easier to grasp the intentions of your work. You can use your favourite GIF screenshare tool for creating animated screenshots.
- Once submitted the PR will be addressed at our earliest convenience.
Code style
Over time this project has accumulated quite an active set of lint rules.
The following are some personal preferences for coding style.
- Functions with more than two arguments should condense these arguments into a parameter object.
- Comment everything. Even if the comment is just to say,
I have no idea what I'm doing
, there is a lot of information in that comment. - Choose simplicity over performance. Performance is abstract and it's often better to start with a simple implementation that can be made more performant, than something that's complex from day one.
- Use
const
Arrow Functions when declaring components.
- Use Function Declarations when creating top level functions.
Creating packages
When creating your own extension or preset you can follow these steps.
- Copy
support/templates/extension-template
topackages/@remirror/extension-<name>
. - Rename
template
,Template
andTEMPLATE
in the new package to<name>
,<Name>
and<NAME>
. - Replace
TEMPLATE_DESCRIPTION
with a suitable description. - Rename the files from
template-
to<name>-
. - (OPTIONAL) -Add your name and email as a contributor to the
package.json
. - Add
packages/remirror/extension/<name>/package.json
. - Add
packages/remirror/src/extension/<name>.ts
. - Edit
packages/remirror/package.json
to add dependency and entrypoint. - (OPTIONAL) - Edit
/.changeset/config.json
and add the package name to the linked array. - Run
pnpm i
in root.
Code of Conduct
Our Pledge
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
Our Standards
Examples of behavior that contributes to creating a positive environment include:
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at help@kickjump.co. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
Attribution
This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at http://contributor-covenant.org/version/1/4