Update package.json

[mreouven]

Checklist:

• If this PR contains changes to the library itself (not necessary for e.g. docs updates), please include a changeset (see CONTRIBUTING.md)
• If this PR is a new feature, please reference an issue where a consensus about the design was reached (not necessary for small changes)
• Make sure all of the significant new logic is covered by tests

[apollo-cla]

@mreouven: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

[netlify]

👷 Deploy request for apollo-client-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	8fda393

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8fda393

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[guyindepurker]

i have the same issue please handle this immediately !!

[phryneas]

Hi there,
unfortunately this PR makes things worse for a lot of our users, and not better for anyone - let me try to explain:

As you can check with this SemVer calculator , the "caret" (^) notation allows for any version that is an equal or higher patch or minor version.

So ^2.3.0 indicated compatibility with 2.3.0, 2.3.1, 2.3.2, 2.4.0, 2.4.1, 2.5.0, and also 2.6.0 etc.

Bumping this to ^2.6.0 will only force all our users to upgrade their tslib to at least 2.6.0, and will cause them troubles if they rely on using an older version for some reason. (Maybe another library depends on a specific version?)

On the other hand, leaving this at ^2.3.0 already allows you to use it with 2.6.0 - no changes needed.

If you see problems in your repository, they are caused by your local package manager, but not by this field in our package.json.

You might need to tell your package manager to e.g. go through it's dependency tree and deduplicate dependent libraries, but this is something that you have to do locally, nothing we can enforce on our whole userbase, and how to do so varies from package manager to package manager.

So I hope you understand that I have to close this PR - but thank you very much for it either way!