question: feature logic

[dargmuesli]

I'm wondering how the feature logic is intended to work:

nupolyon/src/module.ts

Line 32 in e3d10e2

const features = await polyfillist(options.target)

As I understand it, the code currently retrieves all features that are not implemented in browsers which are marked as supported using browserslist and limits the polyfills returned to the matching features.

Now, if that's right, why would you do that?
Isn't the feature list meant to list only the features actually required by website's source, not every feature unsupported by supported browsers?

Example:

Let's say I wanted to support "firefox 116". npx polyfillist "firefox 116" returns:

HTMLInputElement.prototype.valueAsDate
es2023
setImmediate

Now, a browser that uses none of those features would request https://polyfill.io/v3/polyfill.min.js?features=HTMLInputElement.prototype.valueAsDate%2Ces2023%2CsetImmediate which results in 5kb (transferred 3kb).

Wouldn't it be better to expose features as a module option (detecting required features is surely a harder task to solve for now) so that module users can specify which features they use / polyfills they require?

[adenvt]

@dargmuesli Yes, as you mention, this library actually for lazy people (like me 😆) who don't know what features i should to include.

If you know what features should be include, i recommended to use original library from polyfill.io.

[dargmuesli]

Ok, so that logic is meant to load every polyfill for the browsers supported, thus limiting the features to the ones required for supported browsers only, but not to the features actually used. So older browsers are by that definition not meant to be supported at all, which could still be possible if required features were specified instead. Right?

Then would you think we could add that to the README?
And also: what do you think about adding the possibility to specify features (potentially disabling the "everything supported browsers" logic) as module options? Vs. directly using polyfill.io's api, that is.

[adenvt]

@dargmuesli Almost correct, FYI, polyfill.io is service which load polyfill based on User-Agent. But when we want to use polyfill.io, we need to use some kind a preset which feature should be enable.

That way i created polyfillist. it take all features from polyfill.io, check the feature requirement, and return the feature name which possible required in current browserslist config.

But cons of it is some features might be not used in project at all.
And feature which no browser has implemented (like setImmediately) will always included (older and newer browser).

I agree with manual features defined. But for now, i have no plan how to do it. Because it's an array, and config with array always come with 3 possible cases:

• I want to add some item with it (default value + some items)
• I want to remove some of it (default value - some items)
• I want to completely change of it (replace default value)

[dargmuesli]

Ok! I'd propose to keep the current behavior if no custom features property is given and use exactly what's given in the features property if set. Reason being that if someone sets their features they know exactly which ones they require, thus not needing to include all possibly required polyfills for the supported browsers.

That would also enable projects specifying required features to potentially support browsers even older than the ones defined as supported in the browserslist definition, I imagine.