This commit changes "node:http" module to add support
for the "createConnection" option when the "request()"
API is called.
Closes https://github.com/denoland/deno/issues/19507
---------
Signed-off-by: Yoshiya Hinosawa <stibium121@gmail.com>
Signed-off-by: Satya Rohith <me@satyarohith.com>
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: crowlkats <crowlkats@toaxl.com>
Fixes https://github.com/denoland/deno/issues/27289
We exported these but forgot to add them to the list of builtins used by
the resolver, so we weren't resolving bare imports of some modules (e.g.
`"_http_common"`)
Also adds a missing export of `HTTPParser` from `_http_common`
When using the `eval` option on Node's `worker_threads` the code is
passed as a `data:` URL. But we didn't encode the actual code for that,
which lead to syntax errors when including characters not allowed in an
URL.
Fixes a part of https://github.com/denoland/deno/issues/27167
We didn't respect casing when checking if a HTTP header is present in
Node's `ServerResponse.hasHeader()`. This lead to us returning incorrect
results when the header was present. Koa assumed that the `Content-Type`
header wasn't present when it actually was and defaulted to a different
`Content-Type` value.
Fixes https://github.com/denoland/deno/issues/27101
We didn't validate the `path` argument that's passed to `fs.stat()` and
`fs.statSync()` which lead to wrong errors being thrown. The
`@rollup/plugin-node-resolve` code calls it with `undefined` quite a lot
which lead to `nitro` and `nuxt` failing.
Fixes https://github.com/denoland/deno/issues/26700
---------
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
Support for Wasm modules.
Note this implements the standard where the default export is the
instance (not the module). The module will come later with source phase
imports.
```ts
import { add } from "./math.wasm";
console.log(add(1, 2));
```
This will respect `"type": "commonjs"` in a package.json to determine if
`.js`/`.jsx`/`.ts`/.tsx` files are CJS or ESM. If the file is found to
be ESM it will be loaded as ESM though.
This PR fixes #24453, by introducing a ctime (using ctime for UNIX and
ChangeTime for Windows) to Deno.stats.
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
* cts support
* better cjs/cts type checking
* deno compile cjs/cts support
* More efficient detect cjs (going towards stabilization)
* Determination of whether .js, .ts, .jsx, or .tsx is cjs or esm is only
done after loading
* Support `import x = require(...);`
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fixes https://github.com/denoland/deno/issues/26505
I'm not exactly sure how this case comes about (I tried to write tests
for it but couldn't manage to reproduce it), but what happens is the
parent filename ends up null, and we bail out of resolving the specifier
in package exports.
I've checked, and in node the parent filename is also null (so that's
not a bug on our part), but node continues to resolve even in that case.
So this PR should match node's behavior more closely than we currently
do.
Fixes the original issue reported in #26404. storybook runs into other
errors after this PR (the new errors will be fixed in other PRs).
Some code used by a dependency of storybook does a [string comparison on
the error
message](ce30b2be34/node-src/lib/getConfiguration.ts (L88-L92))
thrown here to check for a file not found error.
While testing, I found out that light-my-request relies on
`ServerResponse.connection`, which is deprecated, so I added that and
`socket`, the non deprecated property.
It also relies on an undocumented `_header` property, apparently for
[raw header
processing](https://github.com/fastify/light-my-request/blob/v6.1.0/lib/response.js#L180-L186).
I added it as an empty string, feel free to provide other approaches.
Fixes #19901
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fixes the issue described in
https://github.com/denoland/deno/issues/23882#issuecomment-2423316362.
The parent was starting to send a message right before the process would
exit, and the channel closed in the middle of the write. Unlike with
reads, we weren't cancelling the pending writes, which resulted in a
`Broken pipe` error surfacing to the user.
Fixes https://github.com/denoland/deno/issues/26115.
We weren't normalizing the headers to lower case, so code that attempted
to delete the `Content-Length` header (but used a different case) wasn't
actually removing the header.
