You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+10-21Lines changed: 10 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,35 +36,24 @@ A typical contributor workflow looks like this:
36
36
37
37
1. Create a new feature branch. We like to use a format like `[your-initials]/[short-name]`:
38
38
for example, `bd/refactor-buttons`.
39
-
1. Run development build tasks - follow the ["Developing libraries" steps in the README](https://github.com/palantir/blueprint/blob/develop/README.md#developing-libraries).
40
-
1. Visit http://localhost:9000 in your web browser to see the interactive docs web app.
39
+
2. Run development build tasks - follow the ["Developing libraries" steps in the README](https://github.com/palantir/blueprint/blob/develop/README.md#developing-libraries).
40
+
3. Visit http://localhost:9000 in your web browser to see the interactive docs web app.
41
41
4. Write some code. :hammer:**Refer to the wiki in this repo for detailed instructions on:**
5. Ensure your code **compiles properly** and is **tested**, **linted**, and **formatted**.
46
46
- Run `yarn compile` at the repo root to build all libraries.
47
47
- Run `yarn bundle` at the repo root to build the Blueprint documentation and other bundles.
48
-
- Add unit tests as necessary when fixing bugs or adding features; run them with `yarn test`
49
-
in the relevant package directory.
50
-
- Linting is best handled by your editor for real-time feedback (see
51
-
[Editor integration](https://github.com/palantir/blueprint/wiki/Editor-integration)). Run
52
-
`yarn lint` to be 100% safe.
48
+
- Add unit tests as necessary when fixing bugs or adding features; run them with `yarn test` in the relevant package directory.
49
+
- Linting is best handled by your editor for real-time feedback (see [Editor integration](https://github.com/palantir/blueprint/wiki/Editor-integration)). Run `yarn lint` to be 100% safe.
53
50
- TypeScript lint errors can often be automatically fixed by ESLint. Run lint fixes with `yarn lint-fix`.
54
-
- Code formatting is enforced using [Prettier](https://prettier.io/). These errors can be fixed in your editor
55
-
through the Prettier extension (make sure you have set up the editor integrations linked above).
56
-
__Formatting checks will not run__ during the `yarn lint` package script.
57
-
Instead, when using the CLI or in a CI environment, you should run the `yarn format` script to fix all
58
-
formatting issues across the Blueprint monorepo.
59
-
1. Submit a Pull Request on GitHub and fill out the template.
60
-
- ⚠️ __DO NOT enable CircleCI for your fork of Blueprint.__ When you open a PR, your branch will be checked out
61
-
and built in palantir's CI pipeline automatically. There is no need to enable the CI build for your fork's
62
-
pipeline. If you do, this may cause problems in the CI build.
63
-
- If you have already opened a PR where CircleCI built the code in your own personal or organization pipeline,
64
-
you will likely have to disable the project from building at app.circleci.com/settings/project/github/\<your-username\>/website
65
-
and open a new PR.
66
-
1. Team members will review your code and merge it after approvals.
51
+
- Code formatting is enforced using [Prettier](https://prettier.io/). These errors can be fixed in your editor through the Prettier extension (make sure you have set up the editor integrations linked above). **Formatting checks will not run** during the `yarn lint` package script. Instead, when using the CLI or in a CI environment you should run the `yarn format` script to fix all formatting issues across the Blueprint monorepo.
52
+
6. Submit a Pull Request on GitHub and fill out the template.
53
+
- ⚠️ **DO NOT enable CircleCI for your fork of Blueprint.** When you open a PR, your branch will be checked out and built in palantir's CI pipeline automatically. There is no need to enable the CI build for your fork's pipeline. If you do, this may cause problems in the CI build.
54
+
- If you have already opened a PR where CircleCI built the code in your own personal or organization pipeline, you will likely have to disable the project from building at app.circleci.com/settings/project/github/\<your-username\>/website and open a new PR.
55
+
7. Team members will review your code and merge it after approvals.
67
56
- You may be asked to make modifications to code style or to fix bugs you may have not noticed.
68
57
- Please respond to comments in a timely fashion (even if to tell us you need more time).
69
58
-_Do not_ amend commits and `push --force` as they break the PR history. Please add more commits; we squash each PR to a single commit on merge.
Copy file name to clipboardExpand all lines: README.md
+13-27Lines changed: 13 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -84,15 +84,15 @@ First, ensure you have `nvm` ([Node Version Manager](https://github.com/nvm-sh/n
84
84
After cloning this repo, run:
85
85
86
86
1.`nvm use` to use the supported Node version for Blueprint development.
87
-
1.`corepack enable` to activate [Yarn](https://yarnpkg.com/getting-started) as the Node package manager.
88
-
1.`yarn` to install all dependencies for the monorepo.
89
-
1. If seeing an error like "Error when performing the request ...", you may be using a VPN that needs to be disabled to install the dependencies.
90
-
1. If running on Windows:
87
+
2.`corepack enable` to activate [Yarn](https://yarnpkg.com/getting-started) as the Node package manager.
88
+
3.`yarn` to install all dependencies for the monorepo.
89
+
1. If seeing an error like "Error when performing the request ...", you may be using a VPN that needs to be disabled to install the dependencies.
90
+
4. If running on Windows:
91
91
1.`npm install -g windows-build-tools` to install build tools globally
92
-
1. Ensure `bash` is your configured script-shell by running:<br />
92
+
2. Ensure `bash` is your configured script-shell by running:<br />
93
93
`npm config set script-shell "C:\\Program Files\\git\\bin\\bash.exe"`
94
-
1.`yarn verify` to ensure you have all the build tooling working properly.
95
-
1. There may currently be some errors when running this step, even though everything is set up properly, see https://github.com/palantir/blueprint/issues/6926 for more info.
94
+
5.`yarn verify` to ensure you have all the build tooling working properly.
95
+
1. There may currently be some errors when running this step, even though everything is set up properly, see https://github.com/palantir/blueprint/issues/6926 for more info.
96
96
97
97
### Incorporating upstream changes
98
98
@@ -101,47 +101,33 @@ If you were previously in a working state and have just pulled new code from `de
101
101
- If there were package dependency changes, run `yarn` at the root.
102
102
- This command is very quick if there are no new things to install.
103
103
- Run `yarn compile` to get the latest built versions of the library packages in this repo.
104
-
- This command is quicker than `yarn verify` since it doesn't build the application packages (`docs-app`,
105
-
`landing-app`, etc.) or run tests
104
+
- This command is quicker than `yarn verify` since it doesn't build the application packages (`docs-app`,`landing-app`, etc.) or run tests
106
105
107
106
### Developing libraries
108
107
109
108
There are a few ways to run development scripts, here they are listed from simplest to more advanced usage:
110
109
111
-
- Run `yarn dev` from the root directory to watch changes across all packages and run the docs application with
112
-
webpack-dev-server.
110
+
- Run `yarn dev` from the root directory to watch changes across all packages and run the docs application with webpack-dev-server.
113
111
- Alternately, most libraries have a dev script to run the docs app _and_ watch changes to only that package:
114
112
-`yarn dev:core`
115
113
-`yarn dev:docs`
116
114
-`yarn dev:datetime`
117
115
-`yarn dev:select`
118
116
-`yarn dev:table`
119
-
- Lastly, if you want to control exactly which dev scripts are run and view the console output in the cleanest way,
120
-
we recommend opening separate terminal windows or splits and running local package dev tasks in each one. This is
121
-
the recommended workflow for frequent contributors and advanced developers. For example, to test changes in the core
122
-
and icons packages, you would run the following in separate terminals:
117
+
- Lastly, if you want to control exactly which dev scripts are run and view the console output in the cleanest way, we recommend opening separate terminal windows or splits and running local package dev tasks in each one. This is the recommended workflow for frequent contributors and advanced developers. For example, to test changes in the core and icons packages, you would run the following in separate terminals:
123
118
-`cd packages/core && yarn dev`
124
119
-`cd packages/icons && yarn dev`
125
120
-`cd packages/docs-app && yarn dev`
126
121
127
122
### Updating documentation
128
123
129
-
Much of Blueprint's documentation lives inside source code as JSDoc comments in `.tsx` files and KSS markup in `.scss`
130
-
files. This documentation is extracted and converted into static JSON data using
If you are updating documentation sources (_not_ the docs UI code which lives in `packages/docs-app` or the docs theme
134
-
in `packages/docs-theme`), you'll need to run `yarn compile` from `packages/docs-data` to see changes reflected in the
135
-
application. For simplicity, an alias script `yarn docs-data` exists in the root to minimize directory hopping.
124
+
Much of Blueprint's documentation lives inside source code as JSDoc comments in `.tsx` files and KSS markup in `.scss` files. This documentation is extracted and converted into static JSON data using [documentalist](https://github.com/palantir/documentalist/). If you are updating documentation sources (_not_ the docs UI code which lives in `packages/docs-app` or the docs theme in `packages/docs-theme`), you'll need to run `yarn compile` from `packages/docs-data` to see changes reflected in the application. For simplicity, an alias script `yarn docs-data` exists in the root to minimize directory hopping.
136
125
137
126
### Updating icons
138
127
139
-
The [One-time setup](#one-time-setup) and [Incorporating upstream changes](#incorporating-upstream-changes) steps should
140
-
produce the generated source code in this repo used to build the icons documentation. This is sufficient for most
141
-
development workflows.
128
+
The [One-time setup](#one-time-setup) and [Incorporating upstream changes](#incorporating-upstream-changes) steps should produce the generated source code in this repo used to build the icons documentation. This is sufficient for most development workflows.
142
129
143
-
If you are updating icons or adding new ones, you'll need to run `yarn compile` in `packages/icons` to see those changes
144
-
reflected before running any of the dev scripts.
130
+
If you are updating icons or adding new ones, you'll need to run `yarn compile` in `packages/icons` to see those changes reflected before running any of the dev scripts.
0 commit comments