Contributing
Want to contribute to Slate? That would be awesome!
Reporting Bugs
If you run into any weird behavior while using Slate, feel free to open a new issue in this repository! Please run a search before opening a new issue, to make sure that someone else hasn't already reported or solved the bug you've found.
Any issue you open must include:
A JSFiddle that reproduces the bug with a minimal setup.
A GIF showing the issue in action. (Using something like RecordIt.)
A clear explanation of what the issue is.
Here's a JSFiddle template for Slate to get you started:
Asking Questions
ℹ️ If you're looking for help with the Slate CRM platform, that's an unrelated project to us.
We've also got a Slate Slack team where you can ask questions and get answers from other people using Slate:
Please use the Slack instead of asking questions in issues, since we want to reserve issues for keeping track of bugs and features. We close questions in issues so that maintaining the project isn't overwhelming.
Submitting Pull Requests
All pull requests are super welcomed and greatly appreciated! Issues in need of a solution are marked with a ♥ help label if you're looking for somewhere to start.
Please include tests and docs with every pull request!
Repository Setup
The Slate repository is a monorepo that is managed with lerna. Unlike more traditional repositories, this means that the repository must be built in order for tests, linting, or other common development activities to function as expected.
To run the build, you need to have the Slate repository cloned to your computer. After that, you need to cd into the directory where you cloned it, and install the dependencies with yarn and build the monorepo:
Running Examples
To run the examples, start by building the monorepo as described in the Repository Setup section.
Then you can start the examples server with:
Running Tests
To run the tests, start by building the monorepo as described in the Repository Setup section.
Then you can rerun the tests with:
If you need to debug something, you can add a debugger line to the source, and then run yarn test:inspect.
If you only want to run a specific test or tests, you can run yarn run test:mocha --fgrep="slate-react rendering" flag which will filter the tests being run by grepping for the string in each test. (This is a Mocha flag that gets passed through.)
In addition to tests you should also run the linter:
This will catch TypeScript, Prettier, and Eslint errors.
This will fix Prettier and Eslint errors.
Running integration tests
To run integrations with Playwright, first run yarn start to run the examples website, then run yarn playwright in a separate session to open the Playwright test suite. Or alternatively, run just yarn test:integration-local.
Running integration tests in Docker
If tests fail on CI but pass locally (often due to OS differences), you can run tests in a Docker container that replicates the same environment as CI.
Prerequisites: The project must be built first (same as running tests locally).
The script will automatically:
Start the development server (if not already running)
Run tests inside a Docker container
Stop the server when tests complete
You can also pass additional arguments to the test runner. For example, to run a specific test file:
Or run a specific browser project:
You can combine arguments as well:
Testing Input Methods
Here's a helpful page detailing how to test various input scenarios on Windows, Mac and Linux.
Android tests
When making changes that might affect Android compatibility, you can perform the manual Android tests at /examples/android-tests.
Publishing Releases
Important: When creating releases using Lerna with the instructions below, you will be given choices around how to increase version numbers. You should always use a major, minor or patch release and must never use a prerelease. If a prerelease is used, the root package will not link to the packages in the packages directory creating hard to diagnose issues.
Publishing Normal @latest Release
@latest ReleaseSince we use Lerna to manage the Slate packages this is fairly easy, just run:
And follow the prompts Lerna gives you.
Note that this will automatically run the prelease script first that will build, test and lint before attempting to publish.
Publishing @next Release
@next ReleaseIf we are unsure as to the stability of a release because there are significant changes and/or particularly complex changes, release with the @next tag.
And follow the prompts Lerna gives you.
Publishing @experimental Release
@experimental ReleaseIf you need to create an experimental release to see how a published package will behave during an actual publish, release with the @experimental tag. End users should have no expectation that an @experimental release will be usable.
Running Prerelease Script
If we want to make sure that Slate code follows the preparations for a release but without actually publishing, run:
Which will build, test and lint Slate code.
Last updated