tough-cookie: 4.1 introduced breaking changes

Our jest environment just started throwing errors because allowSpecialUseDomain is now being more enforced in this new release and jest-environment-jsdom doesn’t set it. I tried to correct for it via Jest’s testEnvironmentOptions config passthru, but that produced other problems. You may want to revert that release, it’s gonna break a WHOLE LOT of builds.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 39
  • Comments: 41 (6 by maintainers)

Commits related to this issue

Most upvoted comments

Our jest environment just started throwing errors because allowSpecialUseDomain is now being more enforced in this new release and jest-environment-jsdom doesn’t set it. I tried to correct for it via Jest’s testEnvironmentOptions config passthru, but that produced other problems. You may want to revert that release, it’s gonna break a WHOLE LOT of builds.

If you are using jest@28.x add

testEnvironmentOptions: {
   url: 'https://jestjs.io'
}

to jest config file If you are using earlier version of jest, add

testURL: 'https://jestjs.io'

to jest config file

You can change https://jestjs.io to your url It works on me

https://jestjs.io/docs/upgrading-to-jest28#testurl

We are currently reviewing a p/r that will resolve the issue; once merged we will roll out a new NPM release for tough-cookie to 4.1.1.

Really appreciate everyone’s patience as we do our best for tough-cookie and our customers!

I have raised a PR to fix the version of tough-cookie to v4.0.0 which should fix the immediate problem

jsdom/jsdom#3420

Hey @archer56 . This PR was closed and not merged because he (@domenic) is basically saying (and he is right) that this breaking change should be reverted.

For various reasons our dependency tree is complicated:

@my-repo
├─┬ @our-sub-dependency
│ └─┬ jest-preset-angular@11.1.2
│   └─┬ jest-environment-jsdom@27.5.1
│     └─┬ jsdom@16.7.0
│       └── tough-cookie@4.1.0

@awaterma, @colincasey The temporary solutions posted above are difficult/undoable for us since we have lots of teams depending on our solutions. The real solution is fixing this issue in tough-cookie or reverting the changes since this is a breaking change. I hope you see the importance of this.

We have a new patch for this issue. We believe that we have now resolved a bug for how we treated single word special use domains (localhost and invalid) that should resolve this issue for everyone.

Same here! Happy that this isn’t a bug on our end, was about to throw the computer out the window.

More info: Adding cookies via JSDom adds them to localhost domain … this now errors, cost me about 2 hours

I am also still seeing this issue using 4.1.1:

|-- jest@27.5.1 |— @jest/core@27.5.1 |---- jest-config@27.5.1 |----- jest-environment-jsdom@27.5.1 |------ jsdom@16.7.0 |-------tough-cookie@4.1.1

Did the patch completely revert the change that caused this, or was there a new patch laid over the original change in an attempt to fix?

You can also add as a workaround in your pacakge.json : "overrides": { "jsdom": { "tough-cookie": "4.0.0" } },

Most of us can certainly empathize with these type of challenges so no worries there. We appreciate the work on keeping things compliant.

Al final, i think the best course of action is to move this to version 5; as a practice versions in NPM should live and die with Semver since things are automatically updated and hard to override (using standard NPM client)… By that, I mean RFC targets shouldn’t have any relation to version numbers being used.

@awaterma - I can confirm that 4.1.2 is working for us. Really appreciate the ownership on the issue and swiftness with which the patch was released. Thanks a lot.

Hi @awaterma tests are still failing for me at https://github.com/salesforce/tough-cookie/blob/master/lib/pubsuffix-psl.js#L62. I did a clean install and also included tough-cookie@4.1.1 in package.json dev dependencies. version: node v14.16.0 npm v6.14.1 npm ls tough-cookie:

├─┬ jest@26.6.0
│ └─┬ @jest/core@26.6.3
│   └─┬ jest-config@26.6.3
│     └─┬ jest-environment-jsdom@26.6.2
│       └─┬ jsdom@16.7.0
│         └── tough-cookie@4.1.1  deduped
├─┬ jsdom@15.1.1
│ ├─┬ request@2.88.2
│ │ └── tough-cookie@2.5.0 
│ ├─┬ request-promise-native@1.0.9
│ │ └── tough-cookie@2.5.0 
│ └── tough-cookie@3.0.1 
└── tough-cookie@4.1.1

We’ve released 4.1.1 to NPM:

Screen Shot 2022-08-24 at 12 39 06 PM

I have raised a PR to fix the version of tough-cookie to v4.0.0 which should fix the immediate problem

https://github.com/jsdom/jsdom/pull/3420

I’ll reopen this until we get the 4.1.1 release completed.

@puneetmakkar

This solution totally depends on which package-manager you are using,

for npm v8+, add overrides key for yarn, add it under resolutions key for older npm versions, add a npm-shrinkwrap.json file. or define resolutions and use something like https://www.npmjs.com/package/npm-force-resolutions.

Another workaround is setting your own CookieJar for the jsdom environment:

testEnvironmentOptions: {
  url: 'http://localhost.local/',
  cookieJar: new jsdom.CookieJar(undefined, {
    allowSpecialUseDomain: true,
  }),
},

You have to use a FQDN even for localhost otherwise you will run into https://github.com/salesforce/tough-cookie/issues/248 bug.

Also here to confirm the new version works for us 😃 Thank you!

having the same issue with 4.1.1

For all working with yarn, you can overwrite the though-cookie version by adding this to your package.json:

"resolutions": {
    "tough-cookie": "4.0.0"
}

Thanks to @privateOmega

@CSchulz when I’ve tried that, I get an error that this._cookieJar.getCookieStringSync is not a function

@lyz810 Adding a valid fully qualified domain name for testEnvironmentOptions.url worked for us.

Faced this problem this morning, jest test failing, quick walkaround is to add "tough-cookie": "4.0.0" to package.json file

@awaterma after reviewing a few things, this is definitely a breaking change and probably causing lots of headaches right now. Recommend publishing a rollback minor release and pushing v5 with any updates. For now, we are manually overriding the dep via PNPM as we can’t update JSDom ourselves and there provide no easy way of patching this (e.g. to provide the options recommended in the error)… \

Screen Shot 2022-08-22 at 3 44 12 PM