As the creators and maintainers of this project, we want to ensure that styled-components lives and continues to grow and evolve. The evolution of the library should never be blocked by any single person's time. One of the simplest ways of doing this is by encouraging a larger set of shallow contributors. Through this, we hope to mitigate the problems of a project that needs updates but there's no-one who has the power to do so.
If your Pull Request is merged, regardless of content, you're eligible for push access to the organization on GitHub. This is checked for on pull request merges and an invite is sent automatically. (thanks to an Aeryn instance that @mxstbr runs)
Offhand, it's easy to imagine that this would make code quality suffer, but in reality it offers fresh perspectives to the codebase and encourages ownership from people who are depending on the project. If you are building a project that relies on this codebase, then you probably have the skills to improve it and offer valuable feedback.
Everyone comes in with their own perspective on what a project could/should look like, and encouraging discussion can help expose good ideas sooner.
It can be overwhelming to be offered the chance to wipe the source code for a project. Don't worry, we don't let you push to master. All code has to be reviewed by at least two contributors or one core team member, and we have the convention that someone other than the submitter has to merge non-trivial pull requests.
As an organization contributor, you can merge other people's pull requests, or other contributors can merge yours. You likely won't be assigned a pull request, but you're welcome to jump in and take a code review on topics that interest you.
This project is not continuously deployed, there is space for debate after review too. This means there's always a chance to revert, or to make an amending pull request. If it feels right, merge.
It's normal for a first pull request to be a potential fix for a problem, and moving on from there to helping the project's direction can be difficult. We try to help contributors cross that barrier by offering good first step issues. These issues can be fixed without feeling like you're stepping on toes. Ideally, these are non-critical issues that are well defined. They will be purposely avoided by mature contributors to the project, to make space for others.
We aim to keep all technical discussions inside GitHub issues, and all other discussions in our Spectrum community. This is to make sure valuable discussions are public and discoverable via search engines. If you have questions about a specific PR, want to discuss a new API idea etc GitHub issues are the right place. If you have questions about how to use the library, or how the project is running - the Spectrum community is the place to go.
To quote @alloy from this issue:
Don't ever feel bad for not contributing to open source.
We want contributors to provide ideas, keep the ship shipping and to take some of the load from others. It is non-obligatory; we’re here to get things done in an enjoyable way. 🏆
The fact that you'll have push access will allow you to:
- Avoid having to fork the project if you want to submit other pull requests as you'll be able to create branches directly on the project.
- Help triage issues, merge pull requests.
- Pick up the project if other maintainers move their focus elsewhere.
It's up to you to use those superpowers or not though 😉
If someone submits a pull request that's not perfect, and you are reviewing, it's better to think about the PR's motivation rather than the specific implementation. Having braces on the wrong line should not be a blocker. Though we do want to keep test coverage high, we will work with you to figure that out together.
Max Stoiber and Phil Pluckthun (Twitter links) have contactable emails on their GitHub profiles, and are happy to talk about any problems via those or via Twitter DMs.
It's also important to note that all repositories under the styled-components banner have a Code of Conduct. It is important that you review and enforce this CoC should any violations happen.
Here is a quick guide to doing code contributions to the library.
-
Find some issue you're interested in, or a feature that you'd like to tackle. Also make sure that no one else is already working on it. We don't want you to be disappointed.
-
Fork, then clone:
git clone https://github.com/YOUR_USERNAME/styled-components.git -
Create a branch with a meaningful name for the issue:
git checkout -b fix-something -
Make your changes and commit:
git addandgit commit -
Make sure that the tests still pass:
npm testandnpm run flow(for the type checks) -
Push your branch:
git push -u origin your-branch-name -
Submit a pull request to the upstream styled-components repository.
-
Choose a descriptive title and describe your changes briefly.
-
Wait for a maintainer to review your PR, make changes if it's being recommended, and get it merged.
-
Perform a celebratory dance! 💃
Run yarn install and edit code in the src/ folder. It's luckily very simple! 😉
To make development process easier we provide a Sandbox React application in this repo which automatically uses your local version of the styled-components library. That means when you make any changes in the src/ folder they'll show up automatically there!
To use the sandbox, follow these steps:
-
Go to sandbox folder:
cd sandbox -
Install all the dependencies:
yarn installornpm install -
Run
yarn startornpm startto start sandbox server
Now you should have the sandbox running on localhost:3000. The Sandbox supports client-side and server-side rendering.
You can use an interactive editor, powered by react-live, to test your changes. But if you want more control, you can edit the sandbox itself too:
-
Root
<App>component is located atstyled-components/sandbox/src/App.jsfile -
Client-side entry point is at
styled-components/sandbox/src/browser.js -
Server-side entry point is at
styled-components/sandbox/src/server.js
In the sandbox source, styled-components is an alias to styled-components/src folder, so you can edit the source directly and dev-server will handle rebuilding the source and livereloading your sandbox after the build is done.
When you commit our pre-commit hook will run, which executes lint-staged. It will run the linter automatically and warn you if the code you've written doesn't comply with our code style guidelines.
We have three different benchmarks: mounting a deep tree, mounting a wide tree and updating dynamic styles. Shoutout to @necolas, who wrote these for react-native-web and whom we stole these benchmarks from.
To run the benchmarks run:
yarn run benchmarksYou can also get traces that you can look at in the Chrome DevTools "Performance" panel by running
yarn run benchmarks --tracingWe've recently migrated from pre-commit to husky, so if you're running into issues during this migration, you'll likely have to do the following:
rm .git/hooks/pre-commit*
node ./node_modules/husky/bin/install.jsThis will delete the old pre-commit git hook and install husky's one.
Without the proper uninstallation script of the pre-commit package, this is necessary because husky will skip its installation when
a git hook is already present.
Core team members have the responsibility of pushing new releases to npm. The release process is as follows:
- Install
npby Sindre Sorhus withnpm i -g np. (note: you only have to do this once)npmakes sure that everything is correct and runs tests and a build before it releases the new version for you. - Make sure you have the latest changes and are on the master branch:
git checkout master && git pull origin master - Create a new branch based on the version number, for example
git checkout -b 3.4.1 - Update the CHANGELOG.md with the new version number, add a new Unreleased section at the top and edit the links at the bottom so everything is linked correctly
- Commit the Changelog changes with
git commit -m 'Update CHANGELOG' - Push the branch to the repo with
git push -u origin <branchname> - Run
np --any-branchand follow its instructions - Congratulations, you just published a new release of
styled-components! 🎉 Let everybody know on Twitter, in our community and all the other places
These contribution guidelines are based on https://github.com/moya/contributors, big thanks to @alloy, @orta et al. for the inspiration and guidance.
We also welcome financial contributions in full transparency on our open collective. Anyone can file an expense. If the expense makes sense for the development of the community, it will be "merged" in the ledger of our open collective by the core contributors and the person who filed the expense will be reimbursed.
Thank you to all the people who have already contributed to styled-components!
Thank you to all our backers! [Become a backer]
Thank you to all our sponsors! (please ask your company to also support this open source project by becoming a sponsor)
