Ignore node_modules/ by default

[tyrann0us]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes/features)
• Docs have been added/updated (for bug fixes/features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature

What is the current behavior? (You can also link to an open issue here)
Markdown files in node_module/ are not ignored. Since the likelihood of malformed files from third-party vendors is significantly high, especially for larger packages, users must manually add node_modules/ to the list of ignored folders to avoid false positives when running markdownlint.

What is the new behavior (if this is a feature change)?
This PR adds node_modules as the default value for the --ignore flag.

Since files in this folder are outside the control of the package running markdownlint, it makes no sense not to ignore them by default. This is exactly the reason why other linters like ESLint or Stylelint also ignore node_modules/ by default (see the linked issue for references).

While not empirically correct, searching in (public) code on GitHub shows that of the ~11k usages of the tool (https://github.com/search?q=markdownlint-cli+path%3Apackage.json&type=code), there are ~9k occurrences of "markdownlint ignore node_modules" (https://github.com/search?q=markdownlint+ignore+node_modules&type=code), indicating that the absolute majority of users don't want to scan this folder.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No. If people use node_modules/ incorrectly, they won't know if they are writing malformed Markdown there. However, it can be assumed that developers using markdownlint know what this folder is for.

Other information:
Fixes #405, fixes #459
CC @Chrico

[DavidAnson]

This PR would introduce a silent behavior change for anyone relying on the current behavior - they would lose coverage without realizing it. Also, node_modules is only meaningful to Node developers - other tools and communities have their own special directories which they could argue should be included here as well. I feel the current behavior is the most obvious and understandable.

[tyrann0us]

Hi @DavidAnson, thanks for getting back to me.

This PR would introduce a silent behavior change for anyone relying on the current behavior - they would lose coverage without realizing it.

I understand your concern about potential behavior changes. To address this, we can promote this change as a breaking one through SemVer. This way, users will be informed and can adapt accordingly.

Also, node_modules is only meaningful to Node developers - other tools and communities have their own special directories which they could argue should be included here as well.

Since markdownlint-cli primarily serves Node developers, starting with node_modules/ seems logical. While other communities may have their own directories, shouldn't the focus remain on enhancing the tool's "practicability" within the Node ecosystem?

I appreciate your collaboration and am open to further discussion.

[DavidAnson]

Most people don't read release notes and would not realize this behavior had changed. What's concerning to me is that they would lose coverage of files they may have specifically wanted. And then we'd need to add more code to introduce a mechanism to allow adding back files that get excluded by the new policy so it isn't forced on people. That's even more complexity to solve a something that almost nobody is complaining about.

Regarding the claim this tool is mainly for Node developers, I'm not sure I agree. While it's true this tool runs on Node, there's no requirement that projects that use it be Node-based. For example, anyone using the pre-commit hook or the Docker container image may not have any idea what language this tool was written in.