Added missing browser mapping and default fallback

[pwfcurry]

Previously unknown browsers would cause failures with unhelpful messages, e.g.,

<feature> is not supported in undefined 2.5  compat/compat

I've added a mapping for KaiOS & a fallback to raw name when no mapping is available.

[amilajack]

Thanks for this addition! After adding some tests to this PR, we can merge this. Also please fix the linter errors with yarn lint --fix

[pwfcurry]

Thanks for this addition! After adding some tests to this PR, we can merge this. Also please fix the linter errors with yarn lint --fix

I've fixed the lint error. Due to the external dependency on browserlist I can't see a sensible way to test the fallback behaviour (I've now fixed the specific issue I was having, with kaios), other than exposing the formatTargetNames and unit testing that method only. Suggestions welcome!

[amilajack]

Try something like this in Versioning.spec.js:

it('should support string config in rule option', () => {
  const config = DetermineTargetsFromConfig('some-non-existent-browser-version');
  const result = Versioning(config);
  expect(result).toEqual({
    // ...
  });
});

[pwfcurry]

This will fail because the browserlist dependency doesn't know about "some-non-existent-browser".

This is a non issue if the list of browsers & mappings within this project is always in parity with browserlist. Perhaps there's a better solution to this.

[amilajack]

I think a better solution to this would be using caniuse-db as a peerDependency. @ljharb thoughts on this?

[ljharb]

It’d only need to be a peer if it need to be a singleton - peer deps are required, not optional.