ignore pnpm-lock.yaml by default

[stefanprobst]

Environments:

• Prettier Version: 2.8.4
• Running Prettier via: CLI
• Runtime: Node.js v18.15
• Operating System: Linux
• Prettier plugins (if any):

Steps to reproduce:

• pnpm init
• pnpm add prettier
• pnpm dlx prettier . --check

Expected behavior:

ignore pnpm-lock.yaml when running prettier

Actual behavior:

prettier by default tries to format pnpm-lock.yaml

[kachkaev]

Current implementation of Prettier’s ignore logic does not contain any any special ignore rules except for node_modules. Ignoring common file patterns like pnpm-lock.yaml, .yarn/*, etc., may feel like a simple and good solution, but I’m not sure about that. Once we’ve ignored these ‘obvious’ patterns, what should we do, say, with a feature request to ignore .next/* too (Next.js output)? This app framework is very popular.

The issue has already been discussed in #4547, so I am going to close this one as a duplicate.

I my opinion, What we should probably do instead is introduce composable ignore patterns, similar to what’s possible in ESLint with ignorePatterns. See #4708 and #7073 (there could be other related issues, but I could not find them today).

[SevenOutman]

Current implementation of Prettier’s ignore logic does not contain any any special ignore rules except for node_modules. Ignoring common file patterns like pnpm-lock.yaml, .yarn/*, etc., may feel like a simple and good solution, but I’m not sure about that. Once we’ve ignored these ‘obvious’ patterns, what should we do, say, with a feature request to ignore .next/* too (Next.js output)? This app framework is very popular.

If pnpm-lock.yaml should be considered a "popular framework" thing rather than an "npm basic convention" (like node_modules) because its third-party after all, then what about package-lock.json? It's not ignored by default either. How's that less npm-native than node_modules?