Feature request: export another endpoint that doesn't depend on function-bind and possibly other polyfills

[jedwards1211]

Feature request: export another endpoint that doesn't depend on function-bind and possibly other polyfills

[ljharb]

I really don't agree that it hurts more than it helps; "more bytes than needed" is barely an inconvenience.

The proper approach is for packages - which can make no assumptions about their target environments - to be maximally backwards-compatible and safe, and for apps - where target environments are known and bundlers/build tools are in use - to do whatever patches are needed.

For example, if you only support environments where Function.prototype.bind exists, you can tell your bundler to replace require('function-bind') with Function.bind, and remove the package entirely. You can similarly replace has with Object.hasOwn if that's always available.

[jedwards1211]

I am saying this hurts us more than it helps. I respect your goals to provide maximum backwards compatibility but our goals are different and I would like to see if we can come to some kind of compromise that doesn't involve telling our users to futz with bundler configuration.

[jedwards1211]

Maintaining support for old versions of phantomjs, Internet Explorer < 9, and node < 0.6 doesn't make any kind of business sense for us when it complicates the happy path for our users, none of whom are using our packages in those environments.

[ljharb]

Understood.

I'm not sure it's a viable compromise to add additional weight - and a redundant implementation, forcing all future changes to be made in two places - versus you making a bundler config/plugin that has all the tweaks and users can easily use?

[ljharb]

Especially considering that even if I did what you asked for qs, I maintain hundreds of packages that follow these same patterns - using a bundler is a holistic approach that can work for every current and future instance of this pattern, instead of just trying to fix it one npm package at a time.

[jedwards1211]

what about using an export map to override a module that exports side-channel with a non-polyfilled implementation in more modern environments/bundlers that read the export map? For example

// stringify.js
const getSideChannel = require('qs/side-channel')

{
  "name": "qs",
  "exports": {
    "./side-channel": {
      "legacy": "./side-channel.js",
      "default": "./side-channel-nopolyfill.js"
    }
  }
}

The minority of users who would need to support really old environments could set the legacy exports condition in their bundler if necessary

[jedwards1211]

I think when it comes to really old environments it makes more sense for the compatibility polyfills to be opt-in. That seems to be the philosophy of most other packages I've dealt with...in general the Node ecosystem drops support for old environments too quickly IMO, so I like that you care about maintaining more backwards compatibility, but supporting old versions of phantomjs, Internet Explorer < 9, and node < 0.6 without manual configuration in this day and age seems extreme in the opposite direction. I think most devs would expect to need to manually configure polyfills for many packages to work in such old environments now.

[jedwards1211]

I'm not always opposed to configuration, but this is the only package that's currently an obstacle to a zero-config solution for us, and if all packages in the ecosystem provided backwards compatibility in this way, I can imagine a scenario where I'd have to configure dozens of overrides in my bundler just to get it to build.

[jedwards1211]

I guess another question is - is there truly no way for side-channel to work without doing a .bind for some reason?

[ljharb]

To be clear, call-binding has nothing to do with old implementations - it's about robustness. The only part that's for old impls is the function-bind package - but the actual binding is critical.

could set the legacy exports condition in their bundler if necessary

That doesn't work for node, where bundlers are usually not used.

I think when it comes to really old environments it makes more sense for the compatibility polyfills to be opt-in.

Age doesn't factor in for me.

For side-channel, if you only support envs with WeakMap, some amount of the code could be removed, but call-bind depends on function-bind as mentioned, and call-bind itself is necessary. object-inspect, similarly, uses call-binding all over the place to be robust against builtin modification.