Contributing to the React ecosystem does not only mean pushing code into the React repository. To give back to the community and help developers, you can create packages, blog posts, answer questions on Stack Overflow, and perform many other activities.

Suppose, for example, you created a React component that solves a complex problem, and you think that other developers would benefit from using it instead of investing time in building their solutions. The best thing to do is to publish it GitHub and make it available for everyone to read and use. However, pushing the code to GitHub is only a small action within a big process, and it comes with some responsibilities. So, you should have a clear idea in mind about the reasons behind your choice.

The motivation behind why you want to share your code contributes to improving your skills as a developer. Sharing your code, on the one hand, forces you to follow best practices and write better code. On the other hand, it exposes your code to feedback and comments from other developers. This is a big opportunity for you to receive tips and improve your code to make it better.

Other than the suggestions related to the code itself, by pushing your code to GitHub, you benefit from other people's ideas. In fact, you might have thought about a single problem that your component can solve, but another developer may use it in a slightly different way, finding new solutions for it. Moreover, they might need new features and they could help you implement them, so that everyone, yourself included, can benefit from it. Building software together is a great way to improve both your skills and your packages, and that is why I strongly believe in open source.

Another significant opportunity that open source can give you is letting you get in touch with smart and passionate developers from all around the world. Working closely with new people who have different backgrounds and skill sets is one of the best ways to keep our minds open and improve ourselves.

Sharing code also gives you some responsibilities and it could be time-consuming. In fact, once the code is public and people can use it, you have to maintain it.

Maintaining a repository requires commitment because the more popular it gets and the more people use it, the higher the number of questions and issues. For example, developers may encounter bugs and open issues, so you have to go through all of them and try to reproduce the problems. If the problems exist, then you have to write the fix and publish a new version of the library. You could receive pull requests from developers, which could be long and complex, and they need to be reviewed.

If you decide to ask people to co-maintain the project and help you with issues and pull requests, you have to coordinate with them to share your vision and make decisions together. With this in mind, we can go through some good practices that can help you make a better repository, and avoid some of the common pitfalls.

First of all, if you want to publish your React component, you have to write a comprehensive set of tests. With public code and many people contributing to it, tests are very helpful for many reasons:

• They make the code more robust
• They help other developers understand what the code does
• They make it easier to find regression when new code is added
• They make other contributors more confident in writing the code

The second important thing to do is add a README with a description of the component, an example of its use, and documentation of the APIs and props that can be used.

This helps users of the package, but it also avoids people opening issues and asking questions about how the library works and how it should be used.

It is also essential to add a LICENSE file to your repository to make people aware of what they can and cannot do with your code. GitHub has a lot of ready-made templates to choose from.

Whenever you can, you should keep the package small and add as few dependencies as you can. Developers tend to think carefully about size when they have to decide whether to use a library or not. Remember that heavy packages have a bad impact on performance.

Not only that, depending on too many third-party libraries can create problems if any of them are not maintained or have bugs.

One tricky part in sharing React components comes when you have to decide about the styling. Sharing JavaScript code is pretty straightforward, while attaching the CSS is not as easy as you may think. In fact, there are many different paths you can take to provide it: from adding a CSS file to the package, to using inline styles. The important thing to keep in mind is that CSS is global and generic class names may conflict with the ones that already exist in the project where the component is imported.

The best choice is to include the fewest possible styles and make the component highly configurable for end users. In this way, developers will be more likely to use it because it can be adapted to their custom solutions.

To show that your component is highly customizable, you can add one or more examples to the repository to make it easy for everyone to understand how it works and which props it accepts. Examples are also useful so that you can test new versions of the component and see if there are unexpected breaking changes.

As we saw in Chapter 3, Create Truly Reusable Components, tools such as React Storybook can help you create living style guides, which are easier for you to maintain, and for the consumer of your package to navigate and use.

An excellent example of a highly customizable library that uses Storybook to show all these variations is react-dates from Airbnb. You should take that repository as the perfect example of how to publish React components to GitHub.

As you can see, they use Storybook to show the different options of the component:

Last but not least, you might not only want to share your code—you may also want to distribute your package. The most popular package manager for JavaScript is npm, which we've used throughout this book to install packages and dependencies.

In the next section, we will see how easy it is to publish a new package with npm.

Other than npm, some developers may need to add your component as a global dependency and use it without a package manager.

As we saw in Chapter 1, Taking Your First Steps with React, you can easily use React by just adding a script tag pointing to unpkg.com. It is important to give the users of your library the same option.

So, to offer a global version of your package, you should build the Universal Module Definition (UMD) version as well. With webpack, this is pretty straightforward; you just have to set the libraryTarget in the output section of the configuration file.