[pkg-mime] contenttype to ext #431
Conversation
…eferred extension defined
…d extension not. for backwards compatibility: add `extensionFromMimeOrNull`, and add an `orElse` param for `extensionFromMime` as the standard behavior results in creating an invalid filename.
…ith multiple extensions. There are quite some, but most of them are legacy, and new mimetypes tend to map to 1 extension (no 3 chars limit anymore), so less useful in the future
…nd avoid the linear search
|
This seems to need a major version rev as |
@mosuem thx, now I remember dart-archive/mime#81 (comment) Is it ok though to introduce a major bump, just for this? I mean, is it ok to remove the method, we can as well leave it in and have a non-breaking release which is always better, i guess? better to mark it deprecated? |
|
In my view a major version release is fine, this is why we have semantic versioning. |
|
@mosuem ok, I made a major bump. I thought I'd read some breaking change policy that we'd strive to non-breaking changes as much as possible but I guess it does not apply here 👍 I also fixed the test and added some more default extensions along the way. I'll check the pipeline for any more errors when it runs. |
|
Yes and no - no breaking is the better option if possible, as it makes the fixes and features available to users with restraints of the older version. But this shouldn't keep us from evolving the API if we feel it is needed. |
|
It seems that |
|
@mosuem I realized it is not a function that has been deprecated, but the return value that has become nullable. So I guess making a breaking release is the only option (@lrhn already mentioned we don't want to introduce another method like
Is my reasoning correct? I basically have to create a PR against |
SGTM! |
…ing change. see dart-lang/tools#431 (comment) (cherry picked from commit cbcc1e1)
|
@mosuem i made the PR a few days ago, but I guess it will take some time. Unless maybe you can review there too ;) (or maybe at least trigger a pipeline, I did not manage to run tests locally) |
See dart-lang/tools#431 (comment) An upcoming breaking change does not impact usage in this package.
|
I hit the button to rerun failed checks |
|
thanks @kevmoo . it may be me, because I'm not very familiar with github actions, but I fail to find the rerun of the health checks. Dart CI build job did rerun and seems fine now 🥳 |
|
You might not have the keys to rerun since you're not a member of the repo... |
|
@kevmoo thanks, but I meant, it seems the Dart CI jobs have been rerun, but the health checks do not seem to have been rerun (see timestamps in tooltip popups): Dart CI
Health checks
|
|
@mosuem can you rerun health checks please? they don't seem to have triggered the last time (see previous post) |
Done, but you might need to push an (empty) commit to get the newest hash. Not sure which hash a rerun will take. |
|
@mosuem it seems to have worked, everything's green now! 🎉 ready to merge now? 😊 |
|
Done! Thanks a lot for the changes and the patience :) |
|
@mosuem thanks for helping this move along! Without you it wouldn't have happened ;) |
this is a PR moved from dart-lang/mime repo
I refiled a PR here as requested. I hope this PR can finally be merged now...
based off pr dart-archive/mime#15 , afterwards I realized in the meantime mimeFromExtension had already been added 🙄 but without defaults. I went ahead anyway since @kevmoo https://github.com/dart-lang/tools/issues/397PR's are still welcome.
So this PR mainly adds the defaults and custom error handling (orElse and nullable version), while maintaining backwards compatibility.
example default:
image/jpeg now nicely maps to "jpg" instead of "jpe"
I copied firstWhereOrNull from the collection package to avoid a dependency.
fixes #411
fixes #397
Edit: removed collection dependency