Contribute to the Tailwind CSS community

TW elements is a community-driven, open source project. We welcome your support & contributions.

Start here

There is a few very basic ways you can support the project, even if you don't have the time to contribute code.

Start with sharing your feedback

The easiest way to contribute is to simply share your thoughts on the project :)

GIVE FEEDBACK

Vote on the roadmap

Help the core team make crucial decisions regarding Tailwind Elements development.

You can have a real impact on the future of this project!

vote now

Hey there 👋 we're excited about TW elements and want to see it grow! If you enjoy it, help the project grow by sharing it with your peers. Every share counts, thank you!

Help us improve

Propose new features

To propose a new feature or some other cool idea, post it on our feature request board.

It allows users to upvote the best ideas & helps the core team prioritize the requests.

request a feature

Report bugs

If you found a bug & don't know how to fix it, let us know!

The best way to do this is by creating an issue in our repository and describing wrong behavior of component (or whatever buggy you saw).

create issue

Ask questions

Not sure how to achieve something specific? Or maybe you need someone to explain something in more detail?

If you just can't figure something out, but it's not exactly a bug, make sure to ask for help from our community.

ASK COMMUNITY

Help others

One of the best ways to support the project is to find an issue or a question that you are able to help with.

Important: if someone is assigned to an issue, it means that they are already working on it, find another one ;)

see support questions see issues

Open a Pull Request

Ask first before starting work on any significant new features. It's never a fun experience to have your pull request declined after investing a lot of time and effort. To avoid this from happening, we ask you to create an issue or feature request first, to discuss any significant new features.

Keep your pull requests small to give a PR the best chance of getting accepted. Don't bundle more than one feature or bug fix per pull request. It's always best to create two smaller PRs than one big one.

Package contributions

Fork our repository
The latest dev version of the package is always published on the active branch, named after the version, i.e. v1.0.0-beta2.
In most cases you should start by switching to the active branch, and creating your own branch from it.
Open the forked repo and run npm install in the root of the project
Run npm start in the root of the project to start a demo for testing
Prepare your changes. You should add them in one of the following directories:
- ./src/js/ - source JavaScript
- ./src/scss/ - source SCSS
- ./src/js/plugin.js - plugin customization options
- ./demo/ - demo HTML pages
After making changes, issue a Pull Request to the active branch.
We work on feature branches, so it's 1 branch per feature / per fix, which also means 1 PR per feature / per fix.
The name of the branch should be a descriptive name of the feature that it introduces, in kebab case. For example: fix-input-dark-mode.
Name of the Pull Request consistent with the name of the branch.
For example: Fix input dark mode.

submit a pull request

Documentation contributions

Fork our repository
The latest docs version is always published on the docs branch, simply named docs.
In most cases you should start by switching to the docs branch, and creating your own branch from it.
Open the forked repo and run npm run docs:install in the root of the project
Run npm run docs:start in the root of the project to start a demo for testing
Prepare your changes. You should add them in one of the following directories:
- ./site/content/docs/standard/ - documentation pages
- ./site/layouts/docs/ - documentation templates
After making changes, issue a Pull Request to the docs branch.
We work on feature branches, so it's 1 branch per feature / per fix, which also means 1 PR per feature / per fix.
The name of the branch should be a descriptive name of the feature that it introduces, in kebab case.
For example: fix-typo-in-datepicker.
Name of the Pull Request consistent with the name of the branch. For example: Fix typo in Datepicker documentation.