All contributors must adhere to the code of conduct. Read the full text so that you can understand what actions will and will not be tolerated.
There are many ways to contribute to remote-ui, some of which are:
- Filing bug reports or requesting new features by opening an issue
- Hacking on an issue from our backlog
- Improving tests, documentation, or examples
Clone this repo, then run yarn install
. This repo uses yarn for package management. The codebase is entirely written in TypeScript.
remote-ui uses loom for all development tasks. You will see loom.config.ts
files at the root of the repo, and for each package, which control the way those packages are built, tested, and more.
Run yarn type-check
, which will run TypeScript’s tsc
command on the repo.
This repo uses project references, with each package represented as a project, as well as one project for all the non-source code files (tests, config, etc). Make sure you understand how to configure the tsconfig.json
of projects, like setting the references
key to include the path to any other packages whose types a given project depends on.
Run yarn lint
, which will run the entire codebase through ESLint and Prettier.
Run yarn test
, which will run all tests in the repo in jest’s watch mode.
Tests are currently a little sparse, focused mostly on ensuring good end-to-end behavior when using all the libraries together. Additional tests can be added for public APIs in each package by including files with a .test.ts
or .test.tsx
extension. Make sure you adhere to the structure of the other tests in the repo, and it would be extra appreciated if you understand a little about Shopify’s approach to front-end testing (sorry to external contributors, this is an internal Shopify link).
To build all the package outputs for the repo, run yarn build
. This command builds multiple versions of each package. Some of these versions, like the .esnext
version of the project you will see, preserve most of the original source code, so that build tools can be configured to parse, process, polyfill, and minify this code in the same way the rest of an application’s codebase. This helps to significantly reduce the bundle size of these packages.
yarn build
is automatically run before the project is published. You only need to run it manually when you want to verify the outputs it produces (all of which are ignored in git
).
If this is your first contribution to a project on GitHub, you may find this free video series on contributing to open source useful.
If you are fixing a minor issue, feel free to send a pull request directly. If you are working on a non-trivial bug or feature, though, we’d appreciate if you could first open an issue so we can make sure the process goes smoothly. If you are taking on an issue, please leave a comment stating that you intend to work on it.
Before submitting a pull request, please:
- Fork the repository and create your branch from
main
- Run
yarn install
from the repository root - Make sure your changes do not cause errors to be thrown when running
yarn test
,yarn lint
, oryarn type-check
(these will also be checked automatically when you open your pull request, as they run as part of remote-ui’s GitHub Action-based CI) - Add a description of your changes to package’s
CHANGELOG.md
- Add a changeset using
yarn changeset add
- If you haven’t already, sign a Contributor License Agreement
Each contributor is required to sign a CLA. This process is automated as part of your first pull request and is only required once. If any contributor has not signed or does not have an associated GitHub account, the CLA check will fail and the pull request is unable to be merged.
This repo uses Changesets to manage releases. As you contribute changes to the repo, you can include changeset files that describe the packages being changed, the significance of the change, and a detailed description.
Before you create a PR for your change, run yarn changeset
. This command will prompt you to select the packages and type (patch, minor, or major) of change you are working on. You will also be asked for an initial description.
This command creates a file in the .changeset
directory at the root of the repo. The contents of these files will be included in the changelog entries of each affected package. If you have additional detail or migration instructions related to the change, you can add it as markdown to the generated file.
Once you are satisfied with the content of the file, commit it alongside the rest of your changes, and merge it as part of your normal PR flow. Don’t worry, the new version will not be published immediately! A Shopify developer will take care of actually publishing the new versions.
Note: currently, only Shopify developers can publish new versions of packages.
Once changeset files are merged into the main
branch of this repo, a Github action will create a new PR to apply all the outstanding changesets to their respective packages, creating a new set of package versions. You just need to merge that PR, and the robots will take care of publishing the changes to NPM!