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

Ignore node_modules/ by default #460

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

tyrann0us
Copy link

@tyrann0us tyrann0us commented Feb 21, 2024

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

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.

@KristjanESPERANTO
Copy link

Sorry I don't understand @DavidAnson concerns.

they would lose coverage

In which use case would you like to cover files in node_modules?

node_modules is only meaningful to Node developers

Other developers won't care about the change.

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.

Ignore "node_modules" by default Ignoring of node_modules doesn't work on certain packages
3 participants