-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Development practices
Antoine Llorca edited this page Nov 10, 2016
·
15 revisions
- Follow
README.md
instructions for setting up the dev environment. - Create a local feature branch off the latest
develop
and switch to it.
- Use the naming scheme
<initials>/<short-kebab-case-description>
(example:gg/hot-buttons
). This reduces potential conflicts and signifies a responsible party for the branch so that it can be deleted when stale. - If starting a collaborative or long-lived feature branch, use the naming scheme
feature/<short-description>
.
- Run
gulp
.
- Fix any console errors (caused by merge conflicts, broken unit tests, failed linting, etc.) until the server starts successfully.
- Go to the local LiveReload server at localhost:9000/packages/docs/dist/.
- Write code.
- The dev server will hot-swap CSS changes.
- If you edit KSS markup or TypeScript code, you will need to refresh the page.
- Follow our Coding Guidelines.
- Watch the
gulp
console output for compilation & linting errors; fix them. - Write unit tests for your change.
- Commit your code with a descriptive message.
- If your change resolves an existing issue (usually, it should) include "Fixes #123" on a newline, where 123 is the issue number.
- Push your feature branch to your fork of the
blueprint
repo and open a PR.
- If your change is visual (most Blueprint features are), include a screenshot or GIF demonstrating the change.
- If you have permissions, mark the PR with the label "PR: needs review" so we know it's ready for us. You can use the "Status: work in progress" label if you're not ready for full code review yet.
- Get approval from the Blueprint team.
- When addressing feedback, push additional commits with just the revisions. Be descriptive in your commit messages: prefer "fix style nits" to "address CR feedback" every day because the former provides context at a glance.
- Each successful build will trigger a comment on the PR with a link to the compiled artifacts on Circle. This notification is usually enough to signal reviewers that there are new changes.
- Squash & merge.
- We use GitHub's squash & merge feature to maintain clean history on
develop
. It's great. - If you're not a core contributor, please let a team member merge your PR.
gulp karma
runs all the unit tests in PhantomJS. You may run a specific sub-project's tests via:
gulp karma-blueprint-components
...
Alternatively, gulp karma-unit-<project-name>
runs tests in Chrome where you can debug them more easily.
- Fix the build if you broke it.
- Have lunch/dinner.
- Fix P0 issues.
- Leave the office.
- Review others' pull requests.
- Update an existing pull request based on the code reviewer's feedback.
- Fix P1 issues.
- Fix issues blocking others (in case they aren't already P1).
- Write new code (ERs, FRs, tasks).
- react-day-picker v8 migration
- HotkeysTarget & useHotkeys migration
- PanelStack2 migration
- Table 6.0 changes