Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Jest 29 with JSDom fails because of Cookie jar being more strict #13172

Closed
Smrtnyk opened this issue Aug 25, 2022 · 7 comments
Closed

Comments

@Smrtnyk
Copy link

Smrtnyk commented Aug 25, 2022

Version

29

Steps to reproduce

Try to set and delete a cookie with default jsdom options

Expected behavior

It should delete a cookie, but throws an error

Actual behavior

Basicaly jest sets default testUrl to localhost, and now It throws an 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}

Additional context

It is probably not a bug, but it should be possible to pass in some CookieJar options
this broke the tests
As a workaround I can set the testUrl to some other domain and then change all my tests to expect that domain instead of default one of localhost
This happened today when I updated jest from 28 to 29

Environment

System: 
Windows 11
Node 16.15
@SimenB
Copy link
Member

SimenB commented Aug 25, 2022

See salesforce/tough-cookie#246, not much to be done in Jest. You can possibly force 4.0 via a lockfile?

@SimenB SimenB closed this as not planned Won't fix, can't repro, duplicate, stale Aug 25, 2022
@Smrtnyk
Copy link
Author

Smrtnyk commented Aug 25, 2022

since jest sets default url to localhost, this now conflicts with cookies and jsdom
I think jest could at least set these options if it is going to use localhost as default url for tests
in packages/jest-environment-jsdom/src/index.ts
adding cookieJar instance with {allowSpecialUseDomain:true, rejectPublicSuffixes: false} as options to a JSDOM constructor could fix this I guess

so passing in something like
cookieJar: new CookieJar(void 0, { allowSpecialUseDomain:true, rejectPublicSuffixes: false })

@Smrtnyk
Copy link
Author

Smrtnyk commented Aug 25, 2022

oh I see there they will revert it, nevermind then

@Smrtnyk
Copy link
Author

Smrtnyk commented Aug 25, 2022

You can possibly force 4.0 via a lockfile?

nah, will just wait for update I guess, I am not in a hurry, was only eager to try jest 29 to see if something breaks

@SimenB
Copy link
Member

SimenB commented Aug 25, 2022

Happy to take a PR which passes through options to CookieJar. But yeah, this specific regression is upstream.

Note that jest 28 pulls in same version of tough-cookie (or rather, the jsdom in v28 and the jsdom in v29 does), so there's nothing in the upgrade that should impact this

@Smrtnyk
Copy link
Author

Smrtnyk commented Aug 26, 2022

they fixed the issue so jest 29 now runs properly

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants