filename-case: Add option for multiple file extensions

[michaelowolf]

Fixes #1484

I appreciate there's some discussion on #1484 as to how to approach this, and the final suggestion seems to be to ignore anything after the last two dots.

I've gone with the originally suggested approach of a multipleFileExtensions option, which will effectively treat anything after the first dot as an extension when enabled.

I thought this might be more useful than ignoring those additional parts entirely, as it means the current behaviour (enforcing a specific case for them) is still supported if preferred and executed by default (so backwards compatible), but with the option enabled those parts are enforced as lowercase instead, as the actual extension is already.

[sindresorhus]

The conclusion in #1484 was to just do it by default, but I guess we can have an option for it in case someone complains. But the option should be true by default.

[sindresorhus]

Bump :)

[michaelowolf]

Whoops - this completely slipped my mind! I'll try to get back to it in the next couple of weeks. Thanks for the reminder 😅

[michaelowolf]

@sindresorhus I've updated this to make the option true by default, but I'm getting failures on lint-test after taking latest from main.

It seems there are differences between the updated snapshot file I've pushed and the one the GitHub job produces, but I'm not sure what the best way might be to identify & investigate those differences (especially since they're binary). Weirdly it doesn't look like the snapshot report file is reported as different.

[sindresorhus]

From what I can remember, I think it has something to do with zlib changes in newer Node.js versions. If you're using Node.js 18, maybe try changing to Node.js 20 and regenerate the snapshots ava -u. Also make sure you are on the latest minor version of the Node.js versions.

[michaelowolf]

From what I can remember, I think it has something to do with zlib changes in newer Node.js versions. If you're using Node.js 18, maybe try changing to Node.js 20 and regenerate the snapshots ava -u. Also make sure you are on the latest minor version of the Node.js versions.

That sorted it, thanks! I was actually one Node 16 🙈 but I've also checked 18 and that was producing the wrong snapshot too. 20 has worked.

[fisker]

I'm not sure about this, .SPEC not really in extension, do we really want it to be lowercased?

[michaelowolf]

Sorry, I'm not sure what you mean here - the purpose of this new option is exactly to treat anything after the first dot as an extension instead of the filename.

[michaelowolf]

@fisker could you clarify your comment here?

[fisker]

Sorry not been clear.

Before this PR, this rule check two problems, a) the file base name should match required cases, b) the extension should be lowercased.

For file foo.Test.js it make sense to enforce .js to be lowercased(before), but it doesn't make sense to enforce .Test part to be lowercased(this PR).

[michaelowolf]

Ok, so you're saying you'd rather not enforce any casing on the parts between the first and last .s in the full file name?

[fisker]

I think so, unless you have a better idea.

[michaelowolf]

I like treating everything after the first dot as part of a multi-part file extension. That's implied by the name of the option (multipleFileExtensions). If we'd rather handle it differently, I guess we scrap this PR and start fresh.

[fisker]

I like treating everything after the first dot as part of a multi-part file extension.

It doesn't matter how we treat it, but it doesn't make sense to me to enforce foo.Test.js to be foo.test.js, at least that's not the purpose of #1268

[michaelowolf]

Sure, I had no reference to that issue, but if it's not the intent then we probably just want to start fresh here. 👍

[michaelowolf]

I figure I can be a bit more constructive here -

I think in the context of a rule that enforces file name casing, if we are enforcing lowercase on the last part of the extension then it makes sense to me that it might be useful to offer the option to enforce lowercase on every part of the extension (or "suffix"). Certainly that's the casing that most of the discussed examples in #1484 seem to follow. Ignoring those extra parts entirely means the rule doesn't help users who would prefer to enforce some kind of convention for them, including myself.

Given this change still allows for the original behaviour, I might suggest we go ahead with the behaviour as-is, and could look to improve the rule further in the future by also adding the ability to ignore those extra parts entirely.

[fisker]

Can you add a test for a filename that starts with a dot?

[michaelowolf]

Can you add a test for a filename that starts with a dot?

Done