265 lines
7.5 KiB
Markdown
265 lines
7.5 KiB
Markdown
# Contributing to Theatre.js
|
||
|
||
## Development workflow
|
||
|
||
### Setting up the environment
|
||
|
||
Make sure you have [`node 14+`](https://nodejs.org/) installed:
|
||
|
||
```sh
|
||
$ node -v
|
||
> v14.0.0
|
||
```
|
||
|
||
and [`yarn 1.22+`](https://classic.yarnpkg.com/en/):
|
||
|
||
```sh
|
||
$ yarn -v
|
||
> 1.22.10
|
||
```
|
||
|
||
Then clone the repo:
|
||
|
||
```sh
|
||
# for SSH:
|
||
$ git clone git@github.com:<github-username>/theatre.git
|
||
# for HTTPS:
|
||
$ git clone https://github.com/<github-username>/theatre.git
|
||
|
||
$ cd theatre
|
||
```
|
||
|
||
And fetch the dependencies with yarn:
|
||
|
||
```sh
|
||
$ yarn
|
||
```
|
||
|
||
- Notes about Yarn:
|
||
- This project uses [yarn workspaces](https://yarnpkg.com/features/workspaces)
|
||
so `npm install` will not work.
|
||
- This repo uses Yarn v2. You don't have to install yarn v2 globally. If you
|
||
do have yarn 1.22.10+ on your machine, yarn will automatically switch to v2
|
||
when you `cd` into theatre. Read more about Yarn v2
|
||
[here](https://yarnpkg.com/).
|
||
|
||
### Hacking with `playground`
|
||
|
||
The quickest way to start tweaking things is to run the `playground` package.
|
||
|
||
```sh
|
||
$ cd ./packages/playground
|
||
$ yarn serve
|
||
$ yarn cli build
|
||
# or, shortcut:
|
||
$ cd root
|
||
$ yarn playground
|
||
```
|
||
|
||
The playground is a bunch of ready-made projects that you can run to experiment
|
||
with Theatre.js. It also contains the project's end-to-end tests.
|
||
|
||
Read more at
|
||
[`./packages/playground/README.md`](./packages/playground/README.md).
|
||
|
||
### Hacking with `examples/`
|
||
|
||
Other than `playground`, the [`examples/`](./examples) folder contains a few
|
||
small projects that use Theatre.js with [parcel](https://parceljs.org),
|
||
[Create react app](create-react-app.dev), and other build tools. This means that
|
||
unlike `playground`, you have to build all the packages before running the
|
||
examples.
|
||
|
||
You can do that by running the `build` command at the root of the repo:
|
||
|
||
```sh
|
||
$ yarn cli build
|
||
```
|
||
|
||
Then build any of the examples:
|
||
|
||
```
|
||
$ cd examples/dom-cra
|
||
$ yarn start
|
||
```
|
||
|
||
### Running unit/integration tests
|
||
|
||
We use a single [jest](https://jestjs.io/) setup for the repo. The tests files
|
||
have the `.test.ts` or `.test.tsx` extension.
|
||
|
||
You can run the tests at the root of the repo:
|
||
|
||
```sh
|
||
$ yarn test
|
||
|
||
# or run them in watch mode:
|
||
$ yarn test --watch
|
||
```
|
||
|
||
### Running end-to-end tests
|
||
|
||
End-to-end tests are hosted in the playground package. More details
|
||
[there](./packages/playground/README.md).
|
||
|
||
### Type checking
|
||
|
||
The packages in this repo have full typescript coverage, so you should be able
|
||
to get diagnostics and intellisense if your editor supports typescript.
|
||
|
||
You can also run a typecheck of the whole repo from the root:
|
||
|
||
```sh
|
||
$ yarn typecheck
|
||
|
||
# or in watch mode:
|
||
$ yarn typecheck --watch
|
||
```
|
||
|
||
- If you're using VSCode, we have a ["Typescript watch"](./.vscode/tasks.json)
|
||
task for VSCode that you can use by
|
||
[running](https://code.visualstudio.com/Docs/editor/tasks) "Run Task ->
|
||
Typescript watch".
|
||
- If you wish to contribute code without typescript annotations, that's totally
|
||
fine. We're happy to add the annotations to your PR.
|
||
|
||
### Linting
|
||
|
||
We're using a minimal [ESLint](https://code.visualstudio.com/Docs/editor/tasks)
|
||
setup for linting. If your editor supports ESLint, you should get diagnostics as
|
||
you code. You can also run the lint command from the root of the repo:
|
||
|
||
```sh
|
||
$ yarn lint:all
|
||
```
|
||
|
||
Some lint rules have
|
||
[autofix](https://eslint.org/docs/user-guide/command-line-interface#fixing-problems),
|
||
so you can run:
|
||
|
||
```sh
|
||
$ yarn lint:all --fix
|
||
```
|
||
|
||
### Publishing to npm
|
||
|
||
Currently all packages (except for [`@theatre/r3f`](./packages/r3f/)) share the
|
||
same version number. In order to publish to npm, you can run the `release`
|
||
script from the root of the repo:
|
||
|
||
```sh
|
||
$ yarn cli release x.y.z # npm publish version x.y.z
|
||
$ yarn cli release x.y.z-dev.w # npm publish version x.y.z-dev.w and tag it as "dev"
|
||
$ yarn cli release x.y.z-rc.w # npm publish version x.y.z-rc.w and tag it as "rc"
|
||
```
|
||
|
||
|
||
## Project structure
|
||
|
||
The [monorepo](https://en.wikipedia.org/wiki/Monorepo) consists of:
|
||
|
||
- `@theatre/core` – The core animation library at
|
||
[`./theatre/core`](./theatre/core).
|
||
- `@theatre/studio` – The visual editor at
|
||
[`./theatre/studio`](./theatre/studio).
|
||
- `@theatre/dataverse` – The reactive dataflow library at
|
||
[`./packages/dataverse`](./packages/dataverse).
|
||
- `@theatre/react` – Utilities for using Theatre.js with React at
|
||
[`./packages/react`](./packages/react).
|
||
- `@theatre/r3f` – The react-three-fiber extension at
|
||
[`./packages/r3f`](./packages/r3f).
|
||
- `playground` – The playground explained [above](#hacking-with-playground),
|
||
located at [`./packages/playground`](./packages/playground)
|
||
- `examples/` \* A bunch of [examples](#hacking-with-examples) at
|
||
[./examples](./examples).
|
||
|
||
In addition, each package may contain a `dotEnv/` folder that holds some
|
||
dev-related files, like bundle configuration, lint setup, etc.
|
||
|
||
## Commands
|
||
|
||
These commands are available at the root workspace:
|
||
|
||
```sh
|
||
# Run the playground. It's a shortcut for `cd ./playground; yarn run serve`
|
||
$ yarn playground
|
||
|
||
# Run all the tests.
|
||
$ yarn test
|
||
|
||
# Run tests in watch mode.
|
||
$ yarn test --watch
|
||
|
||
# Typecheck all the packages
|
||
$ yarn typecheck
|
||
|
||
# Typecheck all the packages in watch mode
|
||
$ yarn typecheck --watch
|
||
|
||
# Run eslint on the repo
|
||
$ yarn lint:all
|
||
|
||
# Run eslint and auto fix
|
||
$ yarn lint:all --fix
|
||
|
||
# Build all the packages
|
||
$ yarn cli build
|
||
|
||
```
|
||
|
||
> Yarn passes all extra parameters to the internal scripts. So, for example, if
|
||
> you wish to run the tests in watch mode, you can run `yarn test --watch`.
|
||
|
||
## Documentation
|
||
|
||
The libraries come bundled with typescript definitions with TSDoc comments. You
|
||
can explore the API if your editor is configured to display TSDoc comments.
|
||
|
||
Other references
|
||
|
||
- [Documentation: https://www.theatrejs.com/docs](https://www.theatrejs.com/docs)
|
||
- [API docs: https://www.theatrejs.com/docs/latest/api](https://www.theatrejs.com/docs/latest/api)
|
||
|
||
## What to contribute
|
||
|
||
You can contribute with:
|
||
|
||
- Bug fixes
|
||
- Feature suggestions
|
||
- Features implementations
|
||
- [Documentation](https://github.com/theatre-js/website/) (or write/record
|
||
tutorials of your own which we'll showcase)
|
||
- Create examples projects for your own particular dev stack (eg. using
|
||
Pixie/Vue/THREE.js/Babylon/etc)
|
||
|
||
Another great way to help is to join our
|
||
[community](https://discord.gg/bm9f8F9Y9N) and chime in on questions and share
|
||
ideas.
|
||
|
||
### Helping with outstanding issues
|
||
|
||
Feel free to chime in on any
|
||
[issue](https://github.com/theatre-js/theatre/issues). We have labeled some with
|
||
["Help wanted"](https://github.com/theatre-js/theatre/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22help+wanted%22)
|
||
or
|
||
["Good first issue"](https://github.com/theatre-js/theatre/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22good+first+issue%22)
|
||
if you're just getting started with the codebase.
|
||
|
||
## Sending pull requests
|
||
|
||
We use Github's regular PR workflow. Basically fork the repo, push your commits,
|
||
and send a pull request.
|
||
|
||
If you're a core contributor and have write access to the repo, you should
|
||
submit your pull requests from a branch rather than a personal fork. The naming
|
||
convention for these branches should be:
|
||
|
||
- `(feature|hotfix|docs)/[identifier]` or
|
||
- an autogenerated branch name from a Github issue (On an issue without a PR,
|
||
look under the "Development" sidebar heading for a "create a branch link")
|
||
|
||
Squash & merge should be preferred most of the time to keep the main branch clean, unless the commit history is relevant, in which case rebase should be used.
|
||
|
||
Always update your feature branch with a rebase from the main branch to make sure that you don't accidentally break main with an undetected conflict.
|
||
|
||
Branches belonging to merged PRs should be deleted.
|