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

Run docs through markdown linter #1801

Merged
merged 1 commit into from
Oct 25, 2019
Merged

Run docs through markdown linter #1801

merged 1 commit into from
Oct 25, 2019

Conversation

roji
Copy link
Member

@roji roji commented Oct 2, 2019

Had a bit of an obsessive spurt today so went through all our docs with a linter.

Added .markdownlint.json to help keep things clean. For VS Code there's a great markdownlint plugin which creates warnings - highly recommended.

Copy link
Contributor

@bricelam bricelam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hate it. lol, but I'm willing to conform.

Let's confirm the rendering concerns before merging.


Install the [command-line tools](xref:core/miscellaneous/cli/index):

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I never liked requiring a space before lists. I'm always glad when it's allowed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do find it more readable - after all in actual rendered HTML there's also some spacing (it's like a different paragraph I think).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can always turn off linting rules you don't like. See https://github.com/dotnet/docs/blob/master/.markdownlint.json for an example.
But I do prefer the new line before lists myself.

@@ -74,6 +81,5 @@ if (migrationBuilder.ActiveProvider == "Microsoft.EntityFrameworkCore.SqlServer"
}
```


[1]: ../../miscellaneous/cli/index.md
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like to put two newlines before these to make them feel more like footnotes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MarkdownLinter says no :)

Just kidding, I don't really have strong feelings about most of these, but it seems better to just follow along, otherwise we start to get arbitrary spacing all around the place?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm second guessing using this style of links at all in our docs. They're optimized for reading the raw markdown, but can become tedious when editing it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fully agree, we should just inline links...

@@ -143,8 +146,8 @@ Parameters:

| Parameter | Description |
|:----------------------------------|:------------------------------------------------------------------------------------------------------------------------|
| <nobr>-Name \<String><nobr> | The name of the migration. This is a positional parameter and is required. |
| <nobr>-OutputDir \<String></nobr> | The directory (and sub-namespace) to use. Paths are relative to the target project directory. Defaults to "Migrations". |
Copy link
Contributor

@bricelam bricelam Oct 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These (<nobr>) were to help with rendering. Wrapping looks terrible

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can put back, although is obsolete (there's a CSS for that). Not sure if markdown has a better way of dealing with this. In any case, do you think it's really needed in the first column of this table? Also we don't do this systematically anywhere.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was breaking after they hyphen on smaller screens. I think I tried the css alternative and it didn't work...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bricelam @roji Was there a resolution here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely no strong feelings here, will bring back <nobr> until we see some reason why it's not a good idea.


[!code-csharp[Main](../../../samples/core/Modeling/Conventions/InheritanceDbSets.cs?highlight=3-4&name=Model)]

If you don't want to expose a *DbSet<TEntity>* for one or more entities in the hierarchy, you can use the Fluent API to ensure they are included in the model.
If you don't want to expose a `DbSet<TEntity>` for one or more entities in the hierarchy, you can use the Fluent API to ensure they are included in the model.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Backticks make it a lot more jarring

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC we can also escape it with backslash, I guess it's a separate question of how we refer to things. I'd go even farther and say that the generic adds nothing, we could just talk about DbSet in our documentation...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, it was for the generic. Yeah *DbSet\<TEntity>* would also work. I'm fine with backticks, escaping, or using the non-generic form. You decide

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally think we have too many jarring code fragments in our docs. I really preferred it if we just talked about contexts rather than DbContext<T> (or even DbContext or DbContext). For DbSet I'd go with the non-generic non-quoted version, and so forth.

But that seems like a decision to decide as a team.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bricelam @roji Was a decision made here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it's a general docs question, not really lint-related - we're pretty inconsistent across our docs on this (the linter simply complained about the unescaped angle bracket). We can discuss in design.

Since this point is already pretty inconsistent across our docs, I can just change this back to bold (with backslash) and handle the general question in another issue.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to be consistent with what we do for dotnet/docs, APIs are either inside backticks (to prevent them from being localized) or they use the xref links to link to the API docs.

Copy link
Member

@smitpatel smitpatel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rules should not be disabled unless we have a good justification why we want to deviate from it. The doc authoring pack comes from docs team so they are kind of guidelines for us.

@bricelam
Copy link
Contributor

bricelam commented Oct 2, 2019

The doc authoring pack comes from docs team

But the linter didn't. Do other docs repos have a .markdownlint.json file? Is it more or less consistent?

@bricelam
Copy link
Contributor

bricelam commented Oct 2, 2019

Is there a syntax for suppressing warnings?

<!-- #prama warning disable MD024 -->

@smitpatel
Copy link
Member

@roji
Copy link
Member Author

roji commented Oct 2, 2019

It seems to be possible to suppress in specific places, but I loath the idea of starting to put these in our docs.

@bricelam
Copy link
Contributor

bricelam commented Oct 2, 2019

Hmm, ASP.NET is pretty different than https://github.com/dotnet/docs/blob/master/.markdownlint.json

@roji
Copy link
Member Author

roji commented Oct 2, 2019

Wow, I wasn't even aware all these other repos were doing markdown linter, felt kind of like a trailblazer 😢

@roji
Copy link
Member Author

roji commented Oct 4, 2019

Removed suppression for MD024 (double heading).

Guys, what's the next step here? Is this worth having a full discussion on in design or whatever? I'd like to merge this soon to avoid conflicts etc., we can always do a second wave later and remove more suppressions.

@bricelam
Copy link
Contributor

bricelam commented Oct 4, 2019

I'm fine merging. Ultimately, I only care about the rendering, not the markdown formatting.

@smitpatel
Copy link
Member

I am also ok with merging as long as we don't suppress things. A wrong suppressions means valid issues can go unnoticed.

@roji
Copy link
Member Author

roji commented Oct 4, 2019

I am also ok with merging as long as we don't suppress things. A wrong suppressions means valid issues can go unnoticed.

Can you concretely say what you want us to do with the remaining suppressions? I think I addressed the reasoning behind the remaining four suppressions.

@@ -143,8 +146,8 @@ Parameters:

| Parameter | Description |
|:----------------------------------|:------------------------------------------------------------------------------------------------------------------------|
| <nobr>-Name \<String><nobr> | The name of the migration. This is a positional parameter and is required. |
| <nobr>-OutputDir \<String></nobr> | The directory (and sub-namespace) to use. Paths are relative to the target project directory. Defaults to "Migrations". |
| -Name \<String> | The name of the migration. This is a positional parameter and is required. |
Copy link
Contributor

@mairaw mairaw Oct 15, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if adding the parameters inside backticks could help with the rendering problem or make it worse.

Suggested change
| -Name \<String> | The name of the migration. This is a positional parameter and is required. |
| `-Name <String>` | The name of the migration. This is a positional parameter and is required. |

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably remove the backslash in front of String if you're wrapping in backticks

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW I played around with this a bit... the backticks make the text stand out much more and is quite unnatural/jarring to me. Making the browser very narrow makes the second argument drop to a separate line (i.e. -Name\n<string>) but it seem really OK to me (all very subjective of course).

Unless someone objects (@bricelam?) I'd say we merge as-is (no backticks, no special non-breaking directive).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. Fixed suggestion.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's up to you guys. On the contributor guide they also talk about some new table formats but I've never managed to use them and be successful on solving my rendering issues with them
But leaving here for FYI: https://review.docs.microsoft.com/en-us/help/contribute/markdown-reference?branch=master#tables

@mairaw
Copy link
Contributor

mairaw commented Oct 15, 2019

If you look at the history of our file, you'll see that @nschonni was helping us with those, so you can still consider yourself a trailblazer @roji. 😄

Copy link
Contributor

@nschonni nschonni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, was looking at adding a small GitHub Action over on the dotnet repo to just check stuff as it came in

.markdownlint.json Show resolved Hide resolved
@@ -143,8 +146,8 @@ Parameters:

| Parameter | Description |
|:----------------------------------|:------------------------------------------------------------------------------------------------------------------------|
| <nobr>-Name \<String><nobr> | The name of the migration. This is a positional parameter and is required. |
| <nobr>-OutputDir \<String></nobr> | The directory (and sub-namespace) to use. Paths are relative to the target project directory. Defaults to "Migrations". |
| -Name \<String> | The name of the migration. This is a positional parameter and is required. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably remove the backslash in front of String if you're wrapping in backticks

@roji
Copy link
Member Author

roji commented Oct 15, 2019

@smitpatel @bricelam can someone approve this or post if you have additional issues?

FYI, was looking at adding a small GitHub Action over on the dotnet repo to just check stuff as it came in

That would be really nice!

@nschonni
Copy link
Contributor

FYI, this is the config for the Action setup dotnet/docs#15184

Copy link
Member

@ajcvickers ajcvickers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks generally fine to me, but there were two discussions that I pinged @bricelam and @roji on since they don't seem to be resolved.

We can discuss in the design meeting.

Added .markdownlint.json to help keep things clean
@nschonni
Copy link
Contributor

FYI, the latest version of markdownlint-cli has added a --fix parameter that can automatically correct some of the rules

@roji
Copy link
Member Author

roji commented Oct 24, 2019

FYI, the latest version of markdownlint-cli has added a --fix parameter that can automatically correct some of the rules

Thanks, we'll start slowly by just merging this PR :)

Out of curiousity, are you using --fix in some automated way in a CI pipeline somewhere? Does that mean that it's actually modifying the commit somehow?

@nschonni
Copy link
Contributor

Out of curiousity, are you using --fix in some automated way in a CI pipeline somewhere?

Nope, not on CI, but I've seen that approach in some places with ESLint --fix being used as a pre-commit hook https://github.com/w3c/aria-practices/blob/514af610e735956ada38ac1528dfc2b80ffc6a84/package.json#L44-L58
That approach doesn't do anything for people using GitHub to edit directly, but can be helpful for editors that are developting locally

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants