chore: Run prettier over markdown files (#7192)

.github/ISSUE_TEMPLATE/Bug_report.md

@@ -7,9 +7,9 @@ about: Something not working as expected?
 
 #### Environment
 
-- __Package version(s)__: <!-- fill this out -->
-- __Operating System__: <!-- fill this out -->
-- __Browser name and version__: <!-- fill this out -->
+-   **Package version(s)**: <!-- fill this out -->
+-   **Operating System**: <!-- fill this out -->
+-   **Browser name and version**: <!-- fill this out -->
 
 #### Code Sandbox
 

.github/ISSUE_TEMPLATE/Feature_request.md

@@ -7,8 +7,8 @@ about: Propose a new feature or suggest an idea
 
 #### Environment
 
-- __Package version(s)__: <!-- fill this out -->
-- __Browser and OS versions__: <!-- fill this out -->
+-   **Package version(s)**: <!-- fill this out -->
+-   **Browser and OS versions**: <!-- fill this out -->
 
 #### Feature request
 

.github/ISSUE_TEMPLATE/Support_question.md

@@ -7,8 +7,8 @@ about: Need help with Blueprint?
 
 #### Environment
 
-- __Package version(s)__: <!-- fill this out -->
-- __Browser and OS versions__: <!-- fill this out -->
+-   **Package version(s)**: <!-- fill this out -->
+-   **Browser and OS versions**: <!-- fill this out -->
 
 #### Question
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -2,8 +2,8 @@
 
 #### Checklist
 
-- [ ] Includes tests
-- [ ] Update documentation
+-   [ ] Includes tests
+-   [ ] Update documentation
 
 <!-- DO NOT enable CircleCI for your fork. Our build will run when you open this PR. -->
 

CHANGELOG.md

@@ -1,8 +1,7 @@
-Changelog
----------
+# Changelog
 
 Changelogs for `@blueprintjs/*` packages currently live in the project's Github wiki:
 
-- [5.x Changelog](https://github.com/palantir/blueprint/wiki/5.x-Changelog)
-- [4.x Changelog](https://github.com/palantir/blueprint/wiki/4.x-Changelog)
-- [3.x Changelog](https://github.com/palantir/blueprint/wiki/3.x-Changelog)
+-   [5.x Changelog](https://github.com/palantir/blueprint/wiki/5.x-Changelog)
+-   [4.x Changelog](https://github.com/palantir/blueprint/wiki/4.x-Changelog)
+-   [3.x Changelog](https://github.com/palantir/blueprint/wiki/3.x-Changelog)

CONTRIBUTING.md

@@ -36,35 +36,24 @@ A typical contributor workflow looks like this:
 
 1. Create a new feature branch. We like to use a format like `[your-initials]/[short-name]`:
    for example, `bd/refactor-buttons`.
-1. Run development build tasks - follow the ["Developing libraries" steps in the README](https://github.com/palantir/blueprint/blob/develop/README.md#developing-libraries).
-1. Visit http://localhost:9000 in your web browser to see the interactive docs web app.
+2. Run development build tasks - follow the ["Developing libraries" steps in the README](https://github.com/palantir/blueprint/blob/develop/README.md#developing-libraries).
+3. Visit http://localhost:9000 in your web browser to see the interactive docs web app.
 4. Write some code. :hammer: **Refer to the wiki in this repo for detailed instructions on:**
     - [Development practices](https://github.com/palantir/blueprint/wiki/Development-practices)
     - [Coding guidelines](https://github.com/palantir/blueprint/wiki/Coding-guidelines)
     - [Editor integration](https://github.com/palantir/blueprint/wiki/Editor-integration)
 5. Ensure your code **compiles properly** and is **tested**, **linted**, and **formatted**.
     - Run `yarn compile` at the repo root to build all libraries.
     - Run `yarn bundle` at the repo root to build the Blueprint documentation and other bundles.
-    - Add unit tests as necessary when fixing bugs or adding features; run them with `yarn test`
-      in the relevant package directory.
-    - 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.
+    - Add unit tests as necessary when fixing bugs or adding features; run them with `yarn test` in the relevant package directory.
+    - 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.
     - TypeScript lint errors can often be automatically fixed by ESLint. Run lint fixes with `yarn lint-fix`.
-    - 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.
-1. Submit a Pull Request on GitHub and fill out the template.
-    - ⚠️ __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.
-      - 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.
-1. Team members will review your code and merge it after approvals.
+    - 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.
+6. Submit a Pull Request on GitHub and fill out the template.
+    - ⚠️ **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.
+        - 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.
+7. Team members will review your code and merge it after approvals.
     - You may be asked to make modifications to code style or to fix bugs you may have not noticed.
     - Please respond to comments in a timely fashion (even if to tell us you need more time).
     - _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.
-1. Hooray, you contributed! :tophat:
+8. Hooray, you contributed! :tophat:

README.md

@@ -84,15 +84,15 @@ First, ensure you have `nvm` ([Node Version Manager](https://github.com/nvm-sh/n
 After cloning this repo, run:
 
 1. `nvm use` to use the supported Node version for Blueprint development.
-1. `corepack enable` to activate [Yarn](https://yarnpkg.com/getting-started) as the Node package manager.
-1. `yarn` to install all dependencies for the monorepo.
-   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.
-1. If running on Windows:
+2. `corepack enable` to activate [Yarn](https://yarnpkg.com/getting-started) as the Node package manager.
+3. `yarn` to install all dependencies for the monorepo.
+    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.
+4. If running on Windows:
     1. `npm install -g windows-build-tools` to install build tools globally
-    1. Ensure `bash` is your configured script-shell by running:<br />
+    2. Ensure `bash` is your configured script-shell by running:<br />
        `npm config set script-shell "C:\\Program Files\\git\\bin\\bash.exe"`
-1. `yarn verify` to ensure you have all the build tooling working properly.
-    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. 
+5. `yarn verify` to ensure you have all the build tooling working properly.
+    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.
 
 ### Incorporating upstream changes
 
@@ -101,47 +101,33 @@ If you were previously in a working state and have just pulled new code from `de
 -   If there were package dependency changes, run `yarn` at the root.
     -   This command is very quick if there are no new things to install.
 -   Run `yarn compile` to get the latest built versions of the library packages in this repo.
-    -   This command is quicker than `yarn verify` since it doesn't build the application packages (`docs-app`,
-        `landing-app`, etc.) or run tests
+    -   This command is quicker than `yarn verify` since it doesn't build the application packages (`docs-app`,`landing-app`, etc.) or run tests
 
 ### Developing libraries
 
 There are a few ways to run development scripts, here they are listed from simplest to more advanced usage:
 
--   Run `yarn dev` from the root directory to watch changes across all packages and run the docs application with
-    webpack-dev-server.
+-   Run `yarn dev` from the root directory to watch changes across all packages and run the docs application with webpack-dev-server.
 -   Alternately, most libraries have a dev script to run the docs app _and_ watch changes to only that package:
     -   `yarn dev:core`
     -   `yarn dev:docs`
     -   `yarn dev:datetime`
     -   `yarn dev:select`
     -   `yarn dev:table`
--   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:
+-   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:
     -   `cd packages/core && yarn dev`
     -   `cd packages/icons && yarn dev`
     -   `cd packages/docs-app && yarn dev`
 
 ### Updating documentation
 
-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.
+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.
 
 ### Updating icons
 
-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.
+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.
 
-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.
+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.
 
 ## License
 

packages/core/src/components/alert/alert.md

@@ -1,16 +1,16 @@
 @# Alert
 
-__Alerts__ notify users of important information and force them to acknowledge the alert content before continuing.
+**Alerts** notify users of important information and force them to acknowledge the alert content before continuing.
 
-Although similar to [__Dialog__](#core/components/dialog), an alert is more restrictive and should only be used for
+Although similar to [**Dialog**](#core/components/dialog), an alert is more restrictive and should only be used for
 important information. By default, the user can only exit the alert by clicking one of the confirmation buttons;
 clicking the overlay or pressing the `esc` key will not close the alert. These interactions can be enabled via props.
 
 @reactExample AlertExample
 
 @## Props interface
 
-__Alert__ only supports controlled usage through the `isOpen` prop. Use the `onConfirm` and `onCancel` props to respond
+**Alert** only supports controlled usage through the `isOpen` prop. Use the `onConfirm` and `onCancel` props to respond
 to those interactions separately, or use `onClose` to handle both at the same time.
 
 @interface AlertProps

packages/core/src/components/dialog/dialog.md

@@ -16,7 +16,7 @@ We use the term "dialog" in Blueprint to avoid confusion with the adjective.
 Blueprint provides two types of dialogs:
 
 1.  Standard dialog: show single view using the `<Dialog>` component
-1.  Multi-step dialog: show multiple sequential views using the `<MultistepDialog>` component.
+2.  Multi-step dialog: show multiple sequential views using the `<MultistepDialog>` component.
 
 @## Dialog
 

packages/core/src/components/editable-text/editable-text.md

@@ -1,15 +1,15 @@
 @# Editable text
 
-__EditableText__ is an interactive component which appears as normal UI text. It transforms into an interactive
+**EditableText** is an interactive component which appears as normal UI text. It transforms into an interactive
 text input field when a user hovers and/or focuses on it.
 
 The text input inherits all font styling from its ancestors, making for a seamless transition between reading and
 editing text.
 
 You might use this component for inline renaming, or for an
 [editable multiline description](#core/components/editable-text.multiline-mode).
-You should not use __EditableText__ when a more static, always-editable
-[__InputGroup__](#core/components/input-group) or [__TextArea__](#core/components/text-area)
+You should not use **EditableText** when a more static, always-editable
+[**InputGroup**](#core/components/input-group) or [**TextArea**](#core/components/text-area)
 component would suffice.
 
 @reactExample EditableTextExample
@@ -23,10 +23,9 @@ you should center the component via flexbox or with `position` and `transform: t
 
 </div>
 
-
 @## Multiline mode
 
-By default, __EditableText__ supports _exactly one line of text_ and will grow or shrink horizontally based on the
+By default, **EditableText** supports _exactly one line of text_ and will grow or shrink horizontally based on the
 length of text.
 
 You may enable the `multiline` prop to use a `<textarea>` which spans multiple lines instead of a single-line
@@ -43,7 +42,7 @@ can be inverted with the `confirmOnEnterKey` prop.
 
 @## Usage
 
-__EditableText__ is used like an [`<input>` element](https://facebook.github.io/react/docs/forms.html) and supports
+**EditableText** is used like an [`<input>` element](https://facebook.github.io/react/docs/forms.html) and supports
 controlled or uncontrolled usage through the `value` or `defaultValue` props, respectively. Use `onChange` to listen to
 ongoing updates and use `onConfirm` and `onCancel` to listen only to completed or canceled edits.
 

packages/core/src/components/forms/control-group.md

@@ -1,16 +1,16 @@
 @# Control group
 
-A __ControlGroup__ renders multiple distinct form controls as one unit, with a small margin between elements. It
+A **ControlGroup** renders multiple distinct form controls as one unit, with a small margin between elements. It
 supports any number of buttons, text inputs, input groups, numeric inputs, and HTML selects as direct children.
 
 <div class="@ns-callout @ns-intent-success @ns-icon-comparison @ns-callout-has-body-content">
     <h5 class="@ns-heading">Control group vs. input group</h5>
 
 Both components group multiple elements into a single unit, but their usage patterns are quite different.
 
-Think of __ControlGroup__ as a parent with multiple children, with each one a separate control.
+Think of **ControlGroup** as a parent with multiple children, with each one a separate control.
 
-Conversely, an [__InputGroup__](#core/components/input-group) is a single control, and should behave like
+Conversely, an [**InputGroup**](#core/components/input-group) is a single control, and should behave like
 so. A button inside of an input group should only affect that input; if its reach is further, then it should be
 promoted to live in a control group.
 
@@ -20,15 +20,13 @@ promoted to live in a control group.
 
 @## Flex layout
 
-__ControlGroup__ is a CSS inline flex row (or column if vertical) and provides some modifer props for common flexbox
+**ControlGroup** is a CSS inline flex row (or column if vertical) and provides some modifer props for common flexbox
 patterns:
 
-- Enable the `fill` prop on a control group to make all controls expand equally to fill the available space.
-    - Controls will expand horizontally by default, or vertically if the `vertical` prop is enabled.
-    - Add the class `Classes.FIXED` to individual controls to revert them to their initial sizes.
-
-- In addition, you may enable the `fill` prop on specific controls inside the group to expand them fill more space while
- other controls retain their original sizes.
+-   Enable the `fill` prop on a control group to make all controls expand equally to fill the available space.
+    -   Controls will expand horizontally by default, or vertically if the `vertical` prop is enabled.
+    -   Add the class `Classes.FIXED` to individual controls to revert them to their initial sizes.
+-   In addition, you may enable the `fill` prop on specific controls inside the group to expand them fill more space while other controls retain their original sizes.
 
 You can adjust the specific size of a control with the `flex-basis` or `width` CSS properties.
 
@@ -66,4 +64,3 @@ Note that `.@ns-control-group` does not cascade any modifiers to its children. F
 child must be marked individually as `.@ns-large` for uniform large appearance.
 
 @css control-group
-

packages/core/src/components/forms/file-input.md

@@ -1,6 +1,6 @@
 @# File input
 
-__FileInput__ is a lightweight wrapper around a `<label>` container element which contains an `<input type="file">`.
+**FileInput** is a lightweight wrapper around a `<label>` container element which contains an `<input type="file">`.
 
 @reactExample FileInputExample
 
@@ -20,7 +20,7 @@ To get this behavior, you must update the `text` prop.
 
 @## Props interface
 
-__FileInput__ supports the full range of HTML `<label>` DOM attributes.
+**FileInput** supports the full range of HTML `<label>` DOM attributes.
 Use `inputProps` to forward props to the `<input>` element.
 
 @interface FileInputProps