@sproutsocial/racine

Racine

Installation

Install Racine using npm or yarn:

$ yarn add @sproutsocial/racine react styled-components
# or
$ npm install @sproutsocial/racine react styled-components

You may also require specific peer dependencies when starting a new project or sandbox environment:

@sproutsocial/seeds-border
@sproutsocial/seeds-color
@sproutsocial/seeds-depth
@sproutsocial/seeds-motion
@sproutsocial/seeds-networkcolor
@sproutsocial/seeds-space
@sproutsocial/seeds-typography
moment
prop-types
react
react-dates
styled-components

Then, wrap your app's React root in Racine's ThemeProvider component:

import { ThemeProvider } from "@sproutsocial/racine";

const App = (props) => (
  <ThemeProvider>
    <div>your app here</div>
  </ThemeProvider>
);

Local development

Racine uses Storybook for local development. Please refer to the root README for more information on getting started before continuing.

Testing Racine changes in another project

Spin up a draft PR immediately for two reasons:

1. We'll cache your build making all subsequent builds super fast
2. Add the "📦 create test versions" label to your PR to generate a snapshot version of the package to use for testing in other projects.
3. You'll need to be sure to add a changeset or a bot will comment on your PR prompting you to do so before a snapshot can be created.

Note: the snapshot will post as a comment on the PR once it has been generated.

Documentation

Racine is documented on the Seeds reference site

Racine uses Storybook as a local development environment, and for running tests against components. Every component has a .stories.js file where developers can write "stories" to test components in isolation. Running yarn dev:storybook will open the Racine Storybook in your browser so that you can see changes live as you make them. You can read more about writing stories on the Storybook website.

Contributing

Contributions to Racine are welcomed from any member of the wider Sprout org. Whether you're adding a new component or simply fixing a bug, every improvement to the library is future leverage for our peers, our product, and our customers.

When writing code for Racine, please refer to the code-guidelines.mdx story in Storybook.

🔍 Step 1: Find a way to contribute

There are a few ways to get involved:

• Join #design-systems on Slack to participate in discussions about Racine's development.
• The Design Systems team uses Jira to track our backlog, in-flight changes, and future changes. It's a great way to get a broad look at what's happening in Racine, and tracks the squad's work from sprint to sprint, and release to release.

🗺 Step 2: Find your way around

Racine's file structure is set up like this:

• codemods - For major updates to Racine that have breaking changes, codemods are included for automatically handling component API updates.
• src
  • ComponentName - Every component in Racine has a folder within the src directory.
    • index.js - This file should export the component as its default export.
    • index.stories.js - Storybook stories can be written here.
    • index.test.js - All component tests live inside this file.
    • styles.js - Any style-specific components live here.
  • utils - This directory includes a set of common utilities and helpers that we use throughout Racine.

And you can interact with Racine via the command line with these commands:

• yarn new - This command will prompt you for the name of your component, and then generate all of the boilerplate you need to create the component.
• yarn start - This will watch the Racine package for changes, and also run Storybook locally so that you can see your changes as you go.
• yarn change - This command will generate a changeset file that is used to document changes to the Racine package. If you are making a PR to Racine that should result in a version bump to the package, you will need to run this command to add a changeset. You can learn more about this command in step 3.
• yarn build - Generate production builds for the Racine package.
• yarn test - Run Racine's test suite. Note: yarn start must be run before yarn test to build generated files and directories
• yarn clean - Delete all generated files and directories.
• yarn release - This will trigger the release process for creating a new version of the Racine package on npm. Only Racine administrators can perform the release process.

✅ Step 3: Make your changes

Cut a feature branch off dev and start coding! As updates are merged into dev by other developers over time you'll want to pull those updates into your branch, ideally via rebase, to avoid any conflicts when you open a pull request.

Need to make an urgent update? Branch off main instead of dev, and open your PR later against main. We consider this a hotfix and only support it for critical time-sensitive updates, so check with the Design Systems team prior to making this kind of contribution.

We use a visual regression testing suite to capture any unintended changes during development. After running yarn build you can run the suite locally with yarn test:visual-regression, which will open a report in your browser to show you what passed and what failed. If any fails are actually intentional visual changes you can run yarn backstop:approve to approve those changes as new reference images and include them in your PR.

As you develop you'll want to track the scope of the changes you make. Racine supports this with a tool called changesets to automatically pick new version numbers and update the changelog whenever we publish a new version of the package.

Run yarn change at the root of the Seeds repo to generate a changeset that will be used to derive the next version number for Racine from your changes.

We use semantic versioning for the Racine package, which allows users to understand the scope of a package's changes based on the version number, which is in the format major.minor.patch.

When running this command, you will be asked to select whether your change is a patch, minor, or major change.

• patch changes are for bug fixes, and they bump the last digit in the version number (x.x.0)
• minor changes are for new features or improvements, and they bump the middle digit in the version number (x.0.x)
• major changes are breaking changes, and they bump the first digit (0.x.x). These types of changes are rare and should be coordinated in advance with the Design Systems team.

The changeset CLI will also ask you to input a message detailing your changes. The completion of the command will generate a new changeset markdown file. You are more than welcome to edit this file after it has been generated, so don't get hung up on trying to write the perfect text from the command line. Aim to make the text of the changeset file(s) as descriptive and informative as possible, as they will be used to build a changelog file when the new version is released. Check out our documentation for the Seeds Release Process for examples of what makes a good or bad changeset.

You can add as many changesets to a PR as you would like. If your PR makes several distinct changes to Racine, you should create a changeset detailing each one individually.

🗣 Step 4: Create a pull request

Once you're ready to submit your changes for review, open a PR against the dev branch (it's not the default branch, so you'll have to go find it). A few things will happen:

• The Design Systems team will be tagged to review your code. Feel free to additionally tag any specific individuals who you think should take a look.
• Visual regression testing will run against your PR, and the results can be found in the "Report" artifact on the summary page for the associated Github Action run. html_report/index.html in Report.zip will show you what passed and what failed.
• Racine's test suite will run via CI, and the status will be reported on the PR. You can run yarn test to run these tests locally. If there are any issues, they will need to be resolved before the PR can be merged.
• Netlify will create a preview deploy of Racine's Storybook and include a link to it in a comment on the PR so you can see your changes and share them with others.

You may be asked to make changes to match Racine's contribution guidelines, so expect to keep attention on your PR for a little bit. Once your tests are passing and you have at least one approving Design Systems review, you're welcome to merge your PR. It may sometimes take a little while to get an approval from the DS team since a merge queues your contribution into the next release and the DS team needs to make sure they have the bandwidth to validate any contribution before it releases.

☁️ Step 5: Changes get published to Artifactory

When the Design Systems team prepares the next Racine release, changsets will generate a PR called Version Packages. This PR will detail all of the changes that have been made to the package since the last publish. Merging this PR will release a new version of Racine.

When the PR is merged, GitHub will kick off a publish of the new version. There will be a notification in #design-systems in Slack when the new version is available.

✍ Step 6: Document your changes

Racine components are documented in Seeds, Sprout's design system. You can open a PR to the reference site app to add or edit component documentation. It's a good idea to have documentation changes ready to go at the same time your Racine contributions are deployed, so start early! Reach out to the Design Systems team if you need help getting started.