4.1 introduced breaking changes

[Twipped]

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.

[gbettencourt]

Also breaking our jest tests. Don't see any breaking changes mentioned in the release notes.

[arpowers]

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

[arpowers]

@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)... \

[Jhzl2]

Our jest environment also failed in our tests. We work on a react app but we don't use tough-cookie. We assume that it is a dependency of some installed library. Could you give me a hand?

Locally it does not give us an error, but in github actions it does appear

[awaterma]

I'm sorry this is causing you all some issues! For some background on how to use localhost as a special use domain, please see the discussion and tests in issue #215.

I believe this is coming up for v4.1.0 as @ShivanKaul implemented all of the "special-use" domains per RFC 6761 in the following p/r: https://github.com/salesforce/tough-cookie/pull/203/files, which we included in this release. We view this as continued work for the RFC that we started in v4.0.0.

In regards to working with cookies in localhost please see: https://www.rfc-editor.org/rfc/rfc6761.html#section-6.3

I will reach out to the team in Slack and see if we can get some discussion going. Sorry to cause issues for those that depend upon us; we are working to improve tough-cookie and keep up to date with the relevant RFCs to support cookies correctly into the future!

@colincasey

[arpowers]

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.

[lyz810]

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 [email protected] 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

[privateOmega]

Broke my environment as well. Is there a simple fix for it, other than to pinpoint to the last version?

[MedAmineAyadi96]

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

[danymarques]

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

[antonvialibri1]

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

[AbhaySBhosale]

New version introduced following error
Cookie has domain set to the public suffix "localhost" which is a special use domain. To allow this, configure your CookieJar with {allowSpecialUseDomain:true, rejectPublicSuffixes: false}.

[CSchulz]

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 #248 bug.

[Twipped]

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

[archer56]

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

[CSchulz]

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

Do you have a more detailled stacktrace?

[embeddedt]

Does anyone have a working override config for pnpm?

I've tried:

{
  "pnpm": {
    "overrides": {
      "tough-cookie": "4.0.0"
    }
  }
}

It does not seem to work, as pnpm why tough-cookie shows 4.1.0 still being used.

EDIT: It seems that this works after installing [email protected] as a dev dependency and running pnpm update --depth Infinity.

[matthew-dean]

Ohhh THIS is why all our tests are breaking. 🤦‍♂️

[CSchulz]

Related #248

[puneetmakkar]

failing for me on npm v6. tried both in package.json
"tough-cookie": "4.0.0"
"overrides": { "jsdom": { "tough-cookie": "4.0.0" } }

[privateOmega]

@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.

[Ltchoc221]

I am also still seeing this issue using 4.1.1:

|-- [email protected]
|--- @jest/[email protected]
|---- [email protected]
|----- [email protected]
|------ [email protected]
|[email protected]

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?

[Uninen]

4.1.1 doesn't solve the issue for Vitest users because (at least to my knowledge, please correct me if I'm wrong) there's no way to configure jsdom -- our tests are still failing. (The workaround is to override tough-cookie version to 4.0.0)

vitest 0.22.1
└─┬ jsdom 20.0.0 peer
  └── tough-cookie 4.1.1

[gauravshah27]

4.1.1 - this does not solve the issue.

[gbettencourt]

4.1.1 not working for me either

[LiuJinYang9527]

4.1.1 still not working

[dolevoper]

having the same issue with 4.1.1

[awaterma]

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.

[gauravshah27]

@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.

[SevenOutman]

Also confirm 4.1.2 is working here. For users who had trouble with jsdom/jest, you can add overrides to your package.json and run npm update tough-cookie to bump it to the desired version.

{
  "overrides": {
    "tough-cookie": "4.1.2"
  }
}

Reference: https://stackoverflow.com/a/64273186

[dolevoper]

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