deno_lint VS deno

$ deno lint (prefer-const) `order` is never reassigned let order = new Order() ^^^^^ at /Users/dina/try-deno/design-patterns/state.ts:106:4 hint: Use `const` instead help: for further information visit https://lint.deno.land/#prefer-const Found 24 problems Checked 25 files

I built one of the tools mentioned in the article, Deno's linter. Its binary is over 30 MiB:

After a long time, I started contributing to open-source software. For a long time, I had my eye on Deno. This week, I merged my first PR in Deno Lint. Following is the detailed post about the issue.

I read your latest post about linters and not liking ceremony involved in setting up eslint. Have you tried deno lint by any chance?

https://github.com/denoland/deno_lint

You can use it via the deno binary as well.

// server.ts import { serve } from "https://deno.land/[email protected]/http/server.ts"; serve(() => new Response("Hello Deno"));

Web Audio API afaik is not officially supported by Deno so returns error when trying to invoke new AudioContext. It seems its just a case of enough interest to get the maintainers to officially support it or community to figure how to get it to work (there is a discussion dating a back a while around supporting Web Audio). There is wasm (note this project doesn't actually implement any of the official web spec), but again that isn't going to be native web spec.

import * as Sentry from "@sentry/node"; import * as log from "https://deno.land/[email protected]/log/mod.ts"; Sentry.init({ dsn: "", tracesSampleRate: 1.0, }); async function testEvent() { log.info("Sending test event to Sentry."); try { throw new Error("Nope."); } catch (e) { Sentry.captureException(e); await Sentry.flush(); } } await testEvent();

Deno is not a browser. I don't use denops, but I'd bet the runtime impact is magnitudes smaller than running a browser.

Deno (loosely similar to Node.js, but all code is written in TypeScript)

For another example, JavaScript should have its own set of organized specs based on the kind of environment it will be embedded in and the other technologies that it will have to interact with, just like Wasm does. These could be things like a system embedded runtime (like Deno), a JS-Wasm container for running at the edge and being able to invoke Wasm for heavy computation (like Deno-Deploy), and of course the typical browser environment. As of right now JavaScript has a ton of different APIs that could be applicable in a browser, runtime environments, containers, etc. But there is no standardized way of organizing these and picking/choosing which ones should go into what environment. Maybe WinterCG is a step in the right direction?

proper applications as well. example is the https://deno.land website has an average CPU time of 6ms. CPU time means it doesnt include any IO bound operations, so ie doing a fetch request wont really contribute to the CPU time.

You can use XState in Node.js or Deno to build serverless functions or persistent servers.

The ones I have so far are: - [express.js] (Node.js) - [oak] (Deno) - [gin] (Go) - [vapor] (Swift) - [actix] (Rust) - [rocket] (Rust) - [fastAPI] (Python) - [flask] (Python)