fix: mime-db@1.53.0 #126
fix: mime-db@1.53.0 #126
Conversation
|
I think that’s correct and we should document the expectation in the readme so people can pin. Anything else is a huge pain to maintain. Long sidebar: I have the same issue with |
wesleytodd
force-pushed
the
mimedb-update
branch
from
4e2e71a
to
7982437
Compare
|
@blakeembrey, as discussed in slack I updated the readme to reflect the approach we are taking. Let me know if that is good enough or if you think we need to say more. |
I guess I should have addressed this as well. I think I agree with this but it might put more burden on end users. Going this route would be a breaking change, so we can probably just discuss it out of band of this right? |
Absolutely, by future release I meant future major version. |
| In the past the version of `mime-db` was pinned to give two decision points when adopting MIME data changes. This is no longer true. We still update the | ||
| `mime-db` package here as a `minor` release when necessary, but will use a `^` range going forward. This means that if you want to pin your `mime-db` data | ||
| you will need to do it in your application. While this expectation was not set in docs until now, it is how the pacakge operated, so we do not feel this is | ||
| a breaking change. |
There was a problem hiding this comment.
This sounds good to me. I think the argument is that if you didn't pin already, you expected updates on resolution automatically, and if you did pin, you didn't. This breaks the "you didn't" case, but since those users are currently pinned I agree with the change. Let's ensure the release notes are very clear (big and bold) to highlight this for pinned users.
I still think it's clearer to consider a major version that changes the way the API works and this change at the same time, but it's certainly easier (on both us and users) to consider this non-breaking.
There was a problem hiding this comment.
Looks good to me.
The upstream mime-db advertises the "specs" it pulls its data from. Disagreements with those specs should be handled locally, i.e. if an application considers .js => application/javascript, then that application should do its own inspection for that because the specs mime-db pulls from maps .js => text/javascript.
|
Pending this: jshttp/mime-db#331 I am considering pushing forward with this despite this objection. Since folks are not standing up to share other opinions, I am not sure anything presented has changed my opinion. I think that folks who want a different experience should either fork or pin. That said, we have an opportunity here as we prepare for express v5 to do this one as a major which I think we should take to avoid larger disruption than necessary. If no one objects to that I will re-target this to the next major and work on releasing that. |
wesleytodd
force-pushed
the
mimedb-update
branch
from
7982437
to
0934d27
Compare
|
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/mime-db@1.52.0) |
wesleytodd
force-pushed
the
mimedb-update
branch
from
0934d27
to
bbdbd92
Compare
Updates mime-db which included an update to
.jsmapping to the correctly specifiedtext/javascriptmime type. This broke a test and is likely to be generally disruptive, but I believe that this should be considered non-breaking from a semver perspective since it is to spec. Please tell me why I am wrong before we release this 🤣.EDIT: Copying this comment here so folks understand that I am both saying this from my opinion as well as precidence for this package's history.
#110 (comment)
And note: I removed the pin with this commit. That is up for debate, but I do believe that unless we can get more maintainers around to help with this stuff we plan to optimize for our ability to more quickly ship change in the future, including loosening version ranges like this.
Second edit: I will fix the CI error which is likely because npm that long ago didn't support
^ranges, but I dont want to waste time until we get good agreement on switching to a range in the first place.