-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Conversation
There was a problem hiding this 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): | ||
|
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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". | |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
But the linter didn't. Do other docs repos have a |
Is there a syntax for suppressing warnings? <!-- #prama warning disable MD024 --> |
It seems to be possible to suppress in specific places, but I loath the idea of starting to put these in our docs. |
Hmm, ASP.NET is pretty different than https://github.com/dotnet/docs/blob/master/.markdownlint.json |
Wow, I wasn't even aware all these other repos were doing markdown linter, felt kind of like a trailblazer 😢 |
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. |
I'm fine merging. Ultimately, I only care about the rendering, not the markdown formatting. |
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. | |
There was a problem hiding this comment.
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.
| -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. | |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. Fixed suggestion.
There was a problem hiding this comment.
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
There was a problem hiding this 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
@@ -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. | |
There was a problem hiding this comment.
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
@smitpatel @bricelam can someone approve this or post if you have additional issues?
That would be really nice! |
FYI, this is the config for the Action setup dotnet/docs#15184 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added .markdownlint.json to help keep things clean
FYI, the latest version of markdownlint-cli has added a |
Thanks, we'll start slowly by just merging this PR :) Out of curiousity, are you using |
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 |
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.