First, on behalf of the core maintainers, I'd like to thank you for wanting to contribute and make the user experience for your end-users better and improve the developer experience of this library. 👍🎉 -- @interactivellama
- Read the Codebase Overview to learn concepts and best practices for the codebase and to confirm contribution is within project scope.
- Create a new issue before starting your solution to keep track of what you want to contribute, so that others can offer suggestions, collaborate on a public API (props), or let you know if there is already an effort in progress.
- Fork this repository, clone your fork locally. Create a topic branch locally.
- Add a new component folder to the
/components. - Add all public components exports to
/components/index.jsand the component's name to/components/constants.js - Add documentation site examples and dev storybook stories in
/components/[COMPONENT]/__examples__/. - Hook up storybook and site examples in
/components/[COMPONENT]/__docs__/. Import these examples into Storybook within/components/storybook-stories.jsand/components/site-stories.jsrespectively. Runnpm startto view stories atlocalhost:9001. Site examples only have access to variables exported in/components/index.js, so you should limit your component's site example imports to these variables. See #1192 for more information. - Copy new examples from
/components/storybook-stories.jsto/components/story-based-tests.js. This will add DOM and image snapshot testing for the component. These tests use Storyshots and are run without a DOM. Most props that don't involve the user can be tested here. - Add callback prop tests in Mocha test framework to
/components/[COMPONENT]/__tests__/ - Push to your username's forked repository.
- Send us a well-documented pull request targeting
masterfrom your forked repository. GitHub pull requests should have a descriptive title, a brief summary, @mention several relevant people to review the code, add helpful GitHub comments on lines where you have questions or concerns. All contributors must sign a Contributor License Agreement. - We'll review your code, suggest any needed changes, and hopefully merge it in soon. Thank you!
- Are you a first-time contributor? If you would like a simple task to start out with, you might consider these issues or run
npm run lintand fix a few warnings. - UX pattern / design must exist in SLDS. Components in the process of being added to SLDS will be considered as prototypes.
- All new props and components need tests. Please review the testing readme
- Contributions of components with a subset of SLDS variants will be considered. Please consider your architecture in view of the other variants and create an issue before starting just to be certain.
- Follow this library's
prettier-eslintsettings.npm run lint:fixwill run Prettier and then ESlint and write changes to your files.- You can enable this behavior at save in your editor, too. For instance, in Visual Studio Code, run the prettier extension and set
"editor.formatOnSave": trueandprettier.eslintIntegration: true.
- You can enable this behavior at save in your editor, too. For instance, in Visual Studio Code, run the prettier extension and set
- If you are adding a feature, add a story to the React Storybook that uses your feature, so that reviewers can test it.
- Add enough Storybook stories and testing examples to show use of all component prop and values--if they are enumerated. All examples that are present for a component in the SLDS website should be created as a Storybook story and imported into the documentaiton site examples.
- Prop description tables on the documentation site are generated from
propTypecomments within the component. Usenpm run build-docsto confirm comment compatibility. Introductory component descriptions are generated from the comment directly before the component declaration with react-docgen. - All props descriptions should have a Tested with snapshot testing. or Tested with Mocha framework. notice in them.
- Read through the modified/added code in the pull request.
git clonethis repository. Pull down the pull requested branch. It will be within the contributor's forked repository. For instance,git checkout -b interactivellama-data-table-width masterthengit pull git@github.com:interactivellama/design-system-react.git data-table-width. You could also create an additional remote and pull down the branch directly.- Run
npm installandnpm start. - Review the appropriate Storybook stories at
http://localhost:9001/. - Review tests. Open
http://localhost:8001/and confirm that tests are passing in your browser. - Compare component markup to SLDS markup. Reviewing the snapshot strings is the easiest way. Add year-first date and commit SHA to
last-slds-markup-reviewin package.json and push to pull request branch. - Request a review of the new component/feature by the Salesforce UX Accessibility Team. Add year-first review date, and commit SHA,
last-accessibility-review, topackage.jsonand push to pull request branch.{ "component": "", "status": "prod", "display-name": "", "last-accessibility-review": { "date-iso-8601": "2017/12/31", "commit-sha": "" }, "last-slds-markup-review": { "date-iso-8601": "2017/12/30", "commit-sha": "" }, "SLDS-component-path": "" },
- While the contributor's branch is checked out, run
npm run local-updatewithin locally cloned site repo to confirm the site will function correctly at the next release. This will also build the bundle (npm run dist) and use the bundle in the documentation site and confirm that the bundle works.
- Pull down the documentation site (currenly private) and place in the same parent folder as this library:
git clone git@github.com:salesforce-ux/design-system-react-site.gitand runnpm install. - Run
npm run local-updatefrom withindesign-system-react-siteto build, copy, and serve a local version of this library into the site. You should be able to now view the updated site athttp://localhost:8080/and resolve any issues with updated documentation.