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

Lint all JavaScript in markdown files by default #1355

Open
feross opened this issue Aug 13, 2019 · 5 comments

Comments

@feross
Copy link
Member

commented Aug 13, 2019

ESLint supports the notion of "processors" which allows us to extract JS from markdown files and lint it to ensure it is in standard style. https://eslint.org/docs/user-guide/configuring#specifying-processor

That would let us eliminate this whole section of the readme which describes how to install eslint-plugin-markdown, run standard with the --plugin flag. In the end you need to actually run standard twice if you do this: standard && standard --plugin markdown '**/*.md'

I think we can do better. Let's just do the right thing out of the box.

We should probably do the same for <script> tags in HTML files too, while we're at it.

We can provide a --no-md or --no-html escape hatch for those who need it. But ideally, this just does the right thing 99.9% of the time.

Thoughts?

@feross feross added this to the standard v15 milestone Aug 13, 2019

@feross feross added the question label Aug 13, 2019

@mightyiam

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2019

Brilliant. I'd love that. Would probably break some projects.

Would that be supported merely by extending from eslint-config-standard or would it require the executable? I would prefer the former, if possible.

@feross

This comment has been minimized.

Copy link
Member Author

commented Aug 13, 2019

We'd put it directly in eslint-config-standard.

@vweevers

This comment has been minimized.

Copy link

commented Aug 23, 2019

We should probably do the same for <script> tags in HTML files too, while we're at it.

One requirement for this is that generated HTML (like a code coverage report) is excluded. Such HTML is typically git-ignored though, which tells standard to ignore it too, so it's probably fine.

@vweevers

This comment has been minimized.

Copy link

commented Aug 23, 2019

I've seen and written code examples in READMEs that are not 100% correct, for example to quickly demonstrate two ways to achieve the same thing:

const x = doItOneWay()

// Alternatively:
const x = doItAnotherWay()

I guess standard would implicitly impose a rule to split such snippets? In this case, to not reassign x.

@feross

This comment has been minimized.

Copy link
Member Author

commented Aug 23, 2019

@vweevers Yeah, we'd certainly need to disable some of the rules for examples, like unused variables for example. I think we can look at what standard-markdown disables as a starting point: https://github.com/zeke/standard-markdown/blob/2f044f48eed5f7162147e7927b65a61387200341/lib/linter.js#L8-L15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.