Comments (4)
Hi, @JAspeling. Thanks for reporting this!
This isn't a bug with the Interceptors. I'm talking a bit more about why here: #504 (comment)
from interceptors.
Hi @kettanaito , I know that the bug originates from the fact that jsdom doesn't add these as globals - but the issue I'm trying to resolve is not necessarily because of that.
In our project, we import from @mswjs/interceptors
- the barrel file in src/index.ts exports the following:
export { encodeBuffer, decodeBuffer } from './utils/bufferUtils'
This means that the following code gets executed when importing anything from @mswjs/interceptors
:
const encoder = new TextEncoder()
So basically, even if I do not depend on TextEncoder
in any of our code, this side effect (creating a new instance of TextEncoder
) in the bufferUtils
module causes an error because TextEncoder
is indeed not available as a global when the jest tests execute.
Removing this side-effect from the module fixes the issue for us without the need for any polyfills or declaring it in the test setup - is there a reason why the suggested change #504 is not beneficial to this project?
from interceptors.
Replied here but for others to find this issue: #504 (comment)
I've experienced the same behaviour using the interceptor library and had to add the TextEncoder specifically to the the global jest setup. I agree that this is something probably related to JSDOM as well, but on the other side this code is now introducing a side effect impacting all users. Even when I don't use the TextEncoder I now have to add a polyfill for it.
Secondly I'm wondering why we can't merge this PR and fix it on this side? If I look into the history of the bufferUtils originally the TextEncoder was created every time on the fly: https://github.com/mswjs/interceptors/blob/e305d3815851dbdfd674e2b412f2c2e0288fc1de/src/utils/bufferUtils.ts.
I don't really can find why this has changed in the past (as in why the TextEncoder instantiation is pulled outside to a global variable)
I hope we can revisit this decision and see if it can be fixed for the users of this awesome library!
from interceptors.
@JAspeling, this is derived, I understand it. But deferring TextEncoder
access won't solve anything. There may be other areas in this library, or other libraries, that rely on the global TextEncoder
API, and it will still fail. Deferring all those accesses is not fixing anything. The bottom line in, new TextEncoder()
in a root scope is a valid usage of JavaScript. It's Jest who makes it invalid.
The root cause is that a valid global class in JavaScript is taken away from you by Jest. Since Jest introduces that mutation, it's on Jest's level that the issue must be addressed. I'm not going to add a workaround to support an outdated piece of tech. This is how we drag the entire ecosystem down.
Jest is old. Jest doesn't support ESM, couldn't add proper support for years, and is unlikely to add one in the future. Jest meddles with your environment in a very, very bad way. I've used Jest for years and loved it. As we enter a modern era of JavaScript, tools like Jest have to either adapt or have to go. My developer life has gotten tremendously better after I migrated my projects to Vitest, which I highly recommend you do. The fact that an old tool demands so much of your mental energy is unacceptable.
I hope this explains well why I'm not in favor of this workaround.
from interceptors.
Related Issues (20)
- `Response.type` throws in miniflare-like environments HOT 1
- Support "CONNECT" requests (in proxies) HOT 11
- Support HTTP2 HOT 3
- Intercepted fetch results in the the process never exiting / hangs Mocha tests
- error listener get called twice on mocked error with sync handler HOT 2
- Use "urlToHttpOptions" from "node:url"
- Header keys for requests are being converted to lowercase
- Treat exceptions as 500 responses instead of a "Failed to fetch" error HOT 7
- XMLHttpRequestController creates bad URL when location exists but href not set HOT 4
- Support aborting intercepted requests HOT 6
- WebSocket: Outgoing client events have the wrong "currentTarget" HOT 2
- WebSocket: Decide how to handle actual server errors
- Flaky: `modules/http/response/readable-stream.test.ts`
- ClientRequestInterceptor incorrectly encodes basic authentication header HOT 15
- Abstract request emitting logic
- Await all "response" listeners to finish HOT 4
- Protocol "https:" not supported. Expected "http:" when using "proxy-agent" HOT 1
- Simplify the npm package files HOT 2
- XMLHttpRequest upload (upload.onprogress) event is not supported
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from interceptors.