David Anson

I don’t want to knowingly expose a security vulnerability (even if other packages do), but I’m not sure we need to. If I understand correctly, you are OK with the...

I like the idea, but have a question. In the `@company/markdownlint-config` case you are trying to enable, doesn’t that reference always point to an npm package directory? I’m not sure...

That’s great, but it feels like there will need to be two different types of packages: one that executes code in order to support the existing `.markdownlint.js` feature in the...

`extends` never claims to support JS files, I think. It could be explicit about that in the docs. I don’t think it hides all failures when referencing a file, but...

@kachkaev, in thinking about this in the context of `markdownlint-cli2`, I'm inclined to **allow** auto-discovery of `.markdownlint.js` (like with `.markdownlint.json`) as you originally requested. Assuming I do so, the rest...

The way I read the documentation, replacing one call with the other would break some path scenarios that work today. I'm thinking that it may be necessary to use both...

There's a request to make error/warning configurable per-rule: https://github.com/DavidAnson/markdownlint/issues/254 But for this scenario, could you just ignore the tool's exit code?

FYI that CLI2 has a a GitHub Action ready to go: https://github.com/DavidAnson/markdownlint-cli2-action Here’s how to ignore a failure: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error

Thanks for the proposal! I've only looked briefly on my phone just now. One thing is that we'll need tests for this new code. Another is that it's not clear...

Agreed, the two tools should be consistent. Something like what you propose may be a good approach. For now, running two passes is probably what you want to do. (As...