yup: Bumping to latest version breaks IE11

Describe the bug When bumping to latest YUP version I get a SCRIPT1002 Syntax Error in IE11 in Condition.js The package should be transpiled to IE11.

This version works fine in IE11: "yup": "0.30.0"

This version does not work in IE11: "yup": "0.32.8"

image

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 18
  • Comments: 15 (2 by maintainers)

Most upvoted comments

Sorry folks this was not widely noted, browser support was updated, which dropped below the market share threshold. We took the opportunity to update browser support to modules that natively support ESM, which is https://caniuse.com/es6-module (including safari 10.1) which amounts to about 3-4 years of browser support for major browsers.

This was done in a major update. 0.32.0 if you are considering pre v1 middle version bumps “minor” I would reconsider that, npm and yarn all follow the convention of considering the left most non-zero number to be the “major” version. if you have a caret range e.g. ^0.31.0 it will not update to 0.32.0 automatically.

For folks that continue to need IE 11 support, you have my sympathies! You can continue to use yup by compiling it down further as part of your build process. Tools like create-react-app will do this automatically.

I agree that this should be transpiled to ES5 as part of the package build.

Verified that this just hit us too. We did a minor version upgrade and it broke production. This kind of change feels like it would have justified a major release.

Obviously this library never claims to support IE 11, so it’s reasonable to just have a big warning sign in the README as well, but generally I’ve seen exporting as ES5 to be the standard.

This is true. I have a few dependencies that need transpilation and I use a whilelist for that. But this seems more like a regression in the package build, otherwise I would have thought it would be identified as a breaking change.

Same here, downgrading to 0.31.1 resolved it for me. The issue i’ve seen is:

https://github.com/jquense/yup/blob/master/src/util/printValue.ts#L5

const symbolToString =
  typeof Symbol !== 'undefined' ? Symbol.prototype.toString : () => '';

In versions <0.32.x this was transpiled to the following in the npm package:

var symbolToString = typeof Symbol !== 'undefined' ? Symbol.prototype.toString : function () {
  return '';
};

I feel sincerely sorry for anyone who has to support IE these days. It’s worth escalating within your organisation because no one should be using this unsupported browser. A good place to start is this announcement https://blogs.windows.com/windowsexperience/2022/06/15/internet-explorer-11-has-retired-and-is-officially-out-of-support-what-you-need-to-know/

It’s really less important what the spec says compared to how package managers and tools behave.

strictly speaking according to semver, any version bump pre v1 can be breaking. The npm ecosystem has generally decided on a convention that is more strict than that, which is what yup follows. e.g. treat the left most non-zero digit as the “major” version. All JS package managers respect that convention with their ranges, so using a caret ^ range which is is “allow any minor or patch version” also works with pre v1 versions, in that it will consider 0.1.0 -> 0.2.0 a major (not minor) version change