Yoshiya Hinosawa comments

Results 644 comments of


                                            Yoshiya Hinosawa

feat(cli): add `parse()` with descriptive schema

> Since there is no option object but a collection of properties declared, it is not possible to have named values for options. This is a problem, when one wants...

feat(cli): add `parse()` with descriptive schema

@timreichen BTW what do you think about [`util.parseArgs`](https://nodejs.org/api/util.html#utilparseargsconfig) of Node.js, which is also available in Deno via `node:util` module

md5 checksum of geometry_msgs/PoseWithCovariance is wrong

BTW I was able to calculate the correct number by the following settings (using md5(Pose) = e45d45a5a1ce597b249e23fb30fc871f). ``` $ cat pose.txt e45d45a5a1ce597b249e23fb30fc871f pose float64[36] covariance $ md5 pose.txt MD5 (pose.txt)...

[Bug]: Deployment of a sveltke-kit app fails, telling me that I'm not using the svelte-deno-adapter when I am.

There are 2 sveltekit adapters in npm: `svelte-adapter-deno` and `sveltekit-adapter-deno`. We only detect the latter `sveltekit-adapter-deno` as the adapter for Deno Deploy because the former one has major issue in...

Documentation should take class extensions into consideration

There was a feedback from std users that inherited properties not being shown in API docs is confusing https://github.com/denoland/deno_std/issues/4353 Can we consider listing all properties including inherited ones?

Documentation should take class extensions into consideration

Hyperlink is already available in doc website (jsr). For example, see https://jsr.io/@std/csv/doc/~/CsvParseStreamOptions > This will prevent a significant amount of noise. I'm not sure I agree these are noises. If...

Documentation should take class extensions into consideration

Ok. The above case looks like a valid case where showing inherited props can be noisy. Then how about showing some text link saying `show inherited properties` at the bottom...

feat(dotenv): add the `expectVars` option for typing of return value of `load()`

I'm not sure these checks need to be done as part of `load`. The checks can be done after `load`ing env vars like the below example, which feels more explicit...

feat(dotenv): add the `expectVars` option for typing of return value of `load()`

This kind of type narrowing can be done in a more generic way like [zod](https://github.com/colinhacks/zod) or [valibot](https://github.com/fabian-hiller/valibot). For example, the below example gives a nice typing to `options` (which is...

path.resolve depends on cwd

`path.resolve` can be used for getting `cwd`: ```js import { resolve, dirname } from "https://deno.land/[email protected]/path/mod.ts"; const resolved = resolve("foo"); console.log(resolved); const cwd = dirname(resolved); console.log(cwd); ``` What is the expected...