Yoshiya Hinosawa
Yoshiya Hinosawa
Does the LSP actually run with the above Deno version (`1.43.1`)? What happens if you restart the language server? (via Cmd + Shift + P -> Deno: Restart Language Server)
Thanks for the pointer, Nayeem. Let's track there. Closing this one
These additions are welcome in my opinion. Note to those who are interested in contributing in these areas: Please also consider contributing in Pseudo Terminal support in Deno ( https://github.com/denoland/deno/issues/3994...
Yes, we've been gradually adding support of iterables where they make sense (such as https://github.com/denoland/deno_std/pull/3390 ). PRs are welcome if you find more places suitable for supporting it.
One thing I noticed is that the 3rd params of `copy`, `includesNeedle`, `indexOfNeedle`, and `lastIndexOfNeedle` don't exactly follow [the style guide rule](https://docs.deno.com/runtime/manual/references/contributing/style_guide#exported-functions-max-2-args-put-the-rest-into-an-options-object) (`Exported functions: max 2 args, put the rest...
I think we should recommend esbuild with [esbuild-deno-loader](https://jsr.io/@luca/esbuild-deno-loader) instead of deno_emit for bundling as deno_emit is no longer actively maintained. (`esbuild-deno-loader` already supports `jsr:`)
> IMO, --env is undoubtedly superior to load() for a few reasons. Can you elaborate on this? `--env` is still unstable feature, and I don't see much adoption of it....
`2.` sounds good to me. I still don't get `1.` and `3.` well. > > Can you elaborate on this? What's the main differences? > > Mostly, not throwing when...
-1 to this. Doesn't sound like appropriate reasons for doing breaking changes. > BaseHandler.setup() and BaseHandler.destroy() seem kinda odd as methods for BaseHandler, especially their names. We shouldn't do breaking...
> as they're empty methods solely there to be overwritten. IMO that doesn't justify their existence. This seems suggesting removing all of `setup` and `destroy` methods in `BaseHandler` `ConsoleHandler` `FileHandler`...