broofa / mime

Mime types for JavaScript

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

wasm tests failed when mine@2.4.4

hiroppy opened this issue · comments

If you have an issue with a specific extension or type

Locate the definition for your extension/type in the db.json file in the mime-db project. Does it look right?

I maintain webpack-dev-middleware and use node-mine.
We've already used mime@2.4.2 but we updated to mine@2.4.4 and then have our tests were failed.

Core Code: https://github.com/webpack/webpack-dev-middleware/blob/eb2e32bab57df11bdfbbac19474eb16817d504fe/index.js#L41-L45
Test Code: https://github.com/webpack/webpack-dev-middleware/blob/master/test/server.test.js#L414-L447
Test log: https://dev.azure.com/webpack/webpack-dev-middleware/_build/results?buildId=5158&view=logs&jobId=a846d25a-e32c-5640-1b53-e815fab94407

Is this a breaking change?

Thanks.

I this a breaking change?

Yes and no. I think the issue is that we updated to the latest version of mime-db, which added extensions for some of the types you care about. Those types weren't previously included in mime (no extension = no way to map between extension and type) but, now that they are, they take precedence over custom definitions unless you pass true for the force in mime.define()... which apparently your tests aren't doing.

tl;dr: Add force:true to the options arg here.

Yes, I added force:true but it is a breaking change, right? Why did you change this when you update the patch version? Anyway, thank you for answering.

The mime-db module treats changes to the mime dataset as "minor". I've been less strict about that in this module, treating them as "patch" level changes. While that policy is certainly debatable, I think it's consistent with numerous other libraries out there that version based on structure of the API, not structure of the data the API exposes.

Thank you for the explanation. fmm... Currently, webpack-dev-middleware makes force to false as default so I want to avoid setting true as default...