Add Typescript typings + rework

[kanongil]

I wanted to add official typings to this module. In order to best do this, I added 2 breaking changes.

1. Move default export to Mimos. Ie. the class will now be found at Mimos.Mimos(). This is because Typescript has issues with default exports, and matches what was done in Boom.
2. Change path() to return null when no entry is found (instead of {}) – The {} return was a nonsensical API. Eg. declaring the return value with type MimosEntry | {}, makes it impossible to narrow it. With null it can be done with a simple if (returnedValue).

While I was doing the changes, I found opportunities to speed it up. From the DB setup, the initial load took 10s of ms on my machine. I made several changes to speed it up:

1. Use Map() type instead of POJO for DB storage.
2. Rework compilation using knowledge of source data to avoid expensive clone() and merge() of mime-db data.
3. Use initially compiled DB as basis for overrides (instead of a full re-compile).

The behavior should match the current for common usage, with 2 exceptions for corner cases:

1. The extensions property is assigned with the value from the parsed json. If someone were to modify this mime-db object later, it can change the returned extensions value. I don't believe this will be an issue in practice.
2. The path() lookup might match another (valid) mime-type, if an override was provided for it, and multiple entries share an extension. This is a rare case, that already relies on V8-specific behaviour. It probably works better, since overrides now always take precedence.

For the ´type()` lookup, I made 2 speed-ups:

1. Faster type extraction from provided mime type (removing any options), using indexOf() and slice().
2. Attempt a pre-check with a quick lookup, before doing the expensive .trim().toLowerCase(). This is a heuristic based optimisation, which will make the lookup slightly slower for an upper-cased type lookup, but make it a lot faster for the simple common case.

Since mimos.type() is called on most hapi server responses, this should make hapi slightly faster.

[devinivy]

@kanongil thanks for this. I will review it more closely soon, but this all generally sounds good to me. While I agree with the breaking change regarding the result of path(), I wonder if we should temporarily hold off on this since it is part of hapi's public API via server.mime.

[kanongil]

Hmm, I had not thought about the direct exposure in hapi. Technically, it would not be considered a breaking change from hapi POV, as it is just defined as whatever object mimos created, but I would prefer not to push it.

I guess I will go back to the MimosEntry | {} for now, and TS users will just have to live with it being a pain to use?

It would be handled something like this, for somewhat safe typing:

const entry = mimos.path(path);
if ((entry as MimosEntry).type) {
    const mime = entry as MimosEntry;
    …
}

[Nargonath]

LGTM but it might be a good idea to release progressively with a non-breaking version first. Also shouldn't we create an issue on hapi or create a new major milestone to keep track of all the breaking changes we want to do in the next big version? I believe this is not the first breaking change we postpone and I wonder if we're not going to forget about them as time goes by.

[Marsup]

Wouldn't we benefit from having a kind of citgm for hapi that we could trigger with a matrix of modules and see if at least it builds?

[devinivy]

@Marsup yes, that would be amazing.

@Nargonath sounds good— I will be careful not to resolve this PR without ensuring that additional work is captured somewhere.

[kanongil]

I have given this some further thought, and if we want to go with this change, I would be inclined to just update hapi with it without doing a breaking change. As I already said, this is technically not a breaking change for hapi, but more importantly, even if pushed as a breaking change, it can still cause issues for years since plugins might call into the api, expecting the old behavior. The returned value is a corner-case that could go easily pass 100% test coverage even after such an update.

So I guess the question is, if this instability is worth it. I'm leaning towards: NO. I would rather keep the existing API, and potentially take measures to simplify TS usage of the returned object.

[kanongil]

I undid the path() breaking change.

To make TS usage simple, I export the MimosEntry class and expose it as such in the types. This enables a simple instanceof check on the the returned value, which will correctly narrow the type. Eg.:

const mime = mimos.path(path);
if (mime instanceof MimosEntry) {
    /* mime is ready for use */
    …
}

[devinivy]

Looks good, thanks Gil! I've tested these changes locally against hapi (with some very minor changes within hapi), and all seems to be well there too. I also peeled off the breaking change to mimos.type() proposed here into #38.

[Nargonath]

Found just a little error in the docs otherwise LGTM