Comments (4)
Rather than relying on kState, which most/all fetch classes use to some extent, we can instead add another symbol to each class that contains its type, for example: [kType] = 'Headers'
. Then it should be fine to take the symbol from node classes if it exists or fallback to instanceof. AFAIK this is similar to what Deno does, and it's not vulnerable to Symbol.hasInstance shenanigans, and there's also little chance that we need to introduce a breaking change once it's implemented. We could add in a method to webidl to "brand" these classes, along the lines of:
const kType = require('./symbols')
webidl.brand = function (Clazz, name) {
Object.defineProperty(Clazz.prototype, kType, { value: name })
}
webidl.isBranded = function (instance, name) {
return instance?.[kType] === name
}
class Response { ... }
webidl.brand(Response, 'Response')
webidl.isBranded(new globalThis.Response(...))
webidl.isBranded(new (require('undici').Response)(...))
Alternatively, we can just provide a way of overriding the globals - maybe via a loader or manual api or both. The issue then being with interop with things in node core which relies on the bundled version of undici (such as WebAssembly.instantiateStreaming or OutgoingMessage.setHeaders).
A third option is just to document this difference, rather than attempting to implement incomplete/problematic solutions.
from undici.
How about we get the undici version number from process.versions, find out if they are compatible, and if not consider them different?
This can't lead anywhere but confusing behavior. It can also lock people into old versions of undici. But even more of a problem is that kState, as I mentioned before, can't reliably be used to detect which class it is being used in. Most properties are either optional or overlap between classes. It wouldn't be a sound change either, and addition could break it or maybe there won't be anything else to check at some point...
from undici.
Like your suggestions, overall I would like to know exactly what do we want problems do we want to solve or what use cases do we want to enable; as I see it, the options we have are orthogonal.
Solving the type inference/checking SGTM to follow your suggestion of using a kType
symbol, it overall will simplify a lot of things meanwhile keeping the sanity of the checks.
For undici
"patching", the scope might be different, as it will enable several use cases that we might need to be aware of.
I like the idea of bringing the possibility of loading a version of undici
different to the current one loaded in node
. This has the potential of being really beneficial to situations where new features of undici are of desire for some users but Node hasn't cope with it yeat because of its release cycle (e.g. fetch
updates, or so).
Programmatic seems like a must of enabling this, but loader can be interesting to explore.
One thing we should not do at all, is do this in auto; implementers should explicitly call whatever API we come with to patch Node's
undici
from undici.
Solving the type inference/checking SGTM to follow your suggestion of using a kType symbol, it overall will simplify a lot of things meanwhile keeping the sanity of the checks.
That solves it for me, as long as kType
is a private symbol, which would not solve the problem of using two incompatible versions of undici together.
from undici.
Related Issues (20)
- HTTP2 Requests hang upon receiving 'Stream closed with error code NGHTTP2_INTERNAL_ERROR' HOT 6
- HPE_INVALID_CHUNK_SIZE but works without any issue in curl, browser and other runtimes excluding Node.js HOT 17
- Invalid WebSocket frame: invalid status code 0
- Missed mock request callback
- Incoming security release HOT 1
- Security Update broke test/fetch/pull-dont-push.js? HOT 6
- Issue with undici.request and Headers Global Object HOT 5
- Cannot read properties of null (reading 'destroyed') HOT 2
- Missing v6.6.2 tag/release in github HOT 1
- Semver Major Considerations HOT 20
- Let's add superagent to the benchmark table.
- Move to monorepo HOT 34
- Sending a FormData body and manually providing a content-type header HOT 4
- Missing type updates in `undici.request` HOT 2
- `fetch` support for HTTP/2 by default HOT 12
- fetch: Enable fetch via file URL (under flag) HOT 11
- fetch: caching HOT 15
- CodeCov has wrong base?! HOT 3
- expose MessageEvent for node core HOT 2
- next branch purged of semver-major changes? HOT 4
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 undici.