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

Fix maxLength broken on files with no extension #30

Merged
merged 2 commits into from
Apr 17, 2022
Merged

Fix maxLength broken on files with no extension #30

merged 2 commits into from
Apr 17, 2022

Conversation

tomasklaen
Copy link
Contributor

@tomasklaen tomasklaen commented Apr 16, 2022

Currently, files with no extension are not accounted for when satisfying maxLength, which results in them not being trimmed at all (accident of lastIndexOf() returning -1).

This PR fixes it.

BUT! There is another thing which I personally consider an issue. Currently, maxLength trims only the filename part to the desired length, and then attaches the extension. I haven't changed this behavior in this PR, but I personally don't consider it right. If I want a filename to be 100 chars long, then it should be 100 chars long including the extension, not 100 chars + extension length.

Should I fix this too? And if so, what would be the behavior if it can't be satisfied due to the extension itself being longer than the maxLength requirement?

The options are:

  • We just trim the whole filename from the end as one string, and document extension preservation as a luxury available only for sane inputs. This will break the filename as other apps won't recognize it anymore.
  • Leave the extension and document it → doesn't satisfy maxLength, breaks something else potentially.
  • Throw an error, as the maxLength can't be satisfied without breaking something, but this will bite people in the ass, as this is one of those things that tends to happen only in production.

@astoilkov
Copy link

I like the most the option where only the name without the extension is trimmed. Example: long file name here.md is truncated to long file name.md. Truncation can always be smart and don't cut words in the middle.

filenamify.js Outdated
@@ -35,7 +35,9 @@ export default function filenamify(string, options = {}) {
const allowedLength = typeof options.maxLength === 'number' ? options.maxLength : MAX_FILENAME_LENGTH;
if (string.length > allowedLength) {
const extensionIndex = string.lastIndexOf('.');
string = string.slice(0, Math.min(allowedLength, extensionIndex)) + string.slice(extensionIndex);
const filename = extensionIndex > -1 ? string.slice(0, extensionIndex) : string;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's more readable to check for === -1 as it cannot be another negative number.

@sindresorhus
Copy link
Owner

Should I fix this too?

Yes, that would be great, but should be a separate pull request.

@sindresorhus
Copy link
Owner

I think the max length option is mostly used to prevent abuse and accidental "too long filename" mistakes, so I think just clearly documenting that the length may be larger if the extension is larger than max length, and that it's up to the user to check the length of the returned string if they allow arbitrary file extensions.

@tomasklaen
Copy link
Contributor Author

Yes, that would be great, but should be a separate pull request.

All right, I'll submit it after this is merged, as it affects the same lines of code.

@sindresorhus sindresorhus merged commit a2ee598 into sindresorhus:main Apr 17, 2022
@tomasklaen tomasklaen deleted the maxlength branch April 17, 2022 09:46
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.

3 participants