Why is a detection library using code that is only supported by new browsers?

[SomeProgrammerGuy]

Maybe I'm missing something here so feel free to correct me.

When any library is attempting to detect something that is old then it needs to run on the old thing.

I only linked the ES5 version file and after trying:

var browser = Bowser.getParser(window.navigator.userAgent);

I'm simply met with a "Bowser is not defined" message.

I suspect (without any investigation) that it's because its designed to be understood with such code as:

const Bowser = require("bowser"); // CommonJS

import * as Bowser from "bowser"; // TypeScript

import Bowser from "bowser"; // ES6 (and TypeScript with --esModuleInterop enabled)

Which frankly sort of completely misses the point. In fact why even create a ES5 version if the above is the case.

A detector of this sort should be written for the lowest common denominator (within reason) ONLY. If it isn't then its just completely misses the point. (as lower browsers simply don't understand the detector code).

It's like a thermometer trying to detect temperature wrapped in a heatproof case.

[konstantin-tarasov-clearscale]

It's a good point. I'd suggest @lancedikson to put supported browsers versions to resolve that kind of questions. Here is a good example how to do it.

I definitely like the approach of browser.satisfies(...). But for now I don't know if that library fits to me in reason of system requirements.

[lancedikson]

@SomeProgrammerGuy, thanks for the question, that's a good one.

When any library is attempting to detect something that is old then it needs to run on the old thing.

First of all, bowser is not necessarily supposed to detect something old, as well as it's not necessarily have to run on the old thing. It can run on the latest Node.js project and help to process tons of pre-saved visitors UA strings. So, it's intended to be modern-stack-compatible as well.

When I wrote the second version of it, I didn't want to solve all the issues at once, but I wanted to make the API better to work with, and the codebase more flexible to code. Thus, I intentionally decided to leave this kind of question to developers if they need to, without making the codebase suffer from an old-way syntax or the end-users getting kilobytes of extra polyfills they don't need. Thus, it's up to developers how they use the lib. Need to run it somewhere on an old system? That's fine — just add all the polyfills you need.

Have I had much spare time, I might come up with a solution that would be suitable for every single developer. But I just don't. So, if you have time and ideas, how to solve this issue for the community, please, welcome! I'm open to your ideas and PRs as well. Just one note here: I don't want the codebase turned back to ES5. Moreover, at some point, it would be nice to convert it to TypeScript.

[lancedikson]

Btw, did you try to use the bowser/bundled version? It should have all the needed polyfills already inside. It's mentioned in README.md just below the use cases you pointed above: https://github.com/lancedikson/bowser#use-cases