Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Styleguide path to .mdx #107890

Merged
merged 3 commits into from
Aug 10, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion STYLEGUIDE.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ remove it, don't simply comment it out.

We are gradually moving the Kibana code base over to Prettier. All TypeScript code
and some JavaScript code (check `.eslintrc.js`) is using Prettier to format code. You
can run `node script/eslint --fix` to fix linting issues and apply Prettier formatting.
can run `node scripts/eslint --fix` to fix linting issues and apply Prettier formatting.
We recommend you to enable running ESLint via your IDE.

Whenever possible we are trying to use Prettier and linting over written style guide rules.
Expand Down
2 changes: 1 addition & 1 deletion dev_docs/best_practices.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -171,7 +171,7 @@ Kibana is translated into other languages. Use our i18n utilities to ensure your

## Styleguide

We use es-lint rules when possible, but please review our [styleguide](https://github.com/elastic/kibana/blob/master/STYLEGUIDE.md), which includes recommendations that can't be linted on.
We use es-lint rules when possible, but please review our [styleguide](https://github.com/elastic/kibana/blob/master/STYLEGUIDE.mdx), which includes recommendations that can't be linted on.

Es-lint overrides on a per-plugin level are discouraged.

Expand Down
2 changes: 1 addition & 1 deletion docs/developer/best-practices/index.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ guidelines]
=== Conventions

* Become familiar with our
{kib-repo}blob/{branch}/STYLEGUIDE.md[styleguide]
{kib-repo}blob/{branch}/STYLEGUIDE.mdx[styleguide]
(use Typescript!)
* Write all new code on
{kib-repo}blob/{branch}/src/core/README.md[the
Expand Down
2 changes: 1 addition & 1 deletion docs/developer/contributing/linting.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
== Linting

A note about linting: We use http://eslint.org[eslint] to check that the
link:STYLEGUIDE.md[styleguide] is being followed. It runs in a
link:STYLEGUIDE.mdx[styleguide] is being followed. It runs in a
pre-commit hook and as a part of the tests, but most contributors
integrate it with their code editors for real-time feedback.

Expand Down
2 changes: 1 addition & 1 deletion docs/developer/contributing/pr-review.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -75,7 +75,7 @@ Reviewers are not simply evaluating the code itself, they are also evaluating th

Having a relatively consistent codebase is an important part of us building a sustainable project. With dozens of active contributors at any given time, we rely on automation to help ensure consistency - we enforce a comprehensive set of linting rules through CI. We're also rolling out prettier to make this even more automatic.

For things that can't be easily automated, we maintain a link:{kib-repo}tree/{branch}/STYLEGUIDE.md[style guide] that authors should adhere to and reviewers should keep in mind when they review a pull request.
For things that can't be easily automated, we maintain a link:{kib-repo}tree/{branch}/STYLEGUIDE.mdx[style guide] that authors should adhere to and reviewers should keep in mind when they review a pull request.

Beyond that, we're into subjective territory. Statements like "this isn't very readable" are hardly helpful since they can't be qualified, but that doesn't mean a reviewer should outright ignore code that is hard to understand due to how it is written. There isn't one definitively "best" way to write any particular code, so pursuing such shouldn't be our goal. Instead, reviewers and authors alike must accept that there are likely many different appropriate ways to accomplish the same thing with code, and so long as the contribution is utilizing one of those ways, then we're in good shape.

Expand Down
2 changes: 1 addition & 1 deletion examples/routing_example/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,4 +6,4 @@ Read more:

- [IRouter API Docs](../../docs/development/core/server/kibana-plugin-core-server.irouter.md)
- [HttpHandler (core.http.fetch) API Docs](../../docs/development/core/public/kibana-plugin-core-public.httphandler.md)
- [Routing Conventions](../../STYLEGUIDE.md#api-endpoints)
- [Routing Conventions](../../STYLEGUIDE.mdx#api-endpoints)
3 changes: 2 additions & 1 deletion examples/routing_example/public/app.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -63,7 +63,8 @@ function RoutingExplorer({
},
{
label: 'Conventions',
href: 'https://github.com/elastic/kibana/tree/master/STYLEGUIDE.md#api-endpoints',
href:
'https://github.com/elastic/kibana/tree/master/STYLEGUIDE.mdx#api-endpoints',
iconType: 'logoGithub',
target: '_blank',
size: 's',
Expand Down