21–30 of 190 posts
Ava ( https://github.com/avajs/ava ) gets too little love from the blogging machinery. It's a breeze to use with TS, faster than Jest (YMMV of course), and I love the snapshot output over any other snapshot producing unit test tool. Use with NYC for coverage is a breeze.
Earlier quoted context omitted.
Please stop spreading this misnomer. It's an alternative platform. It's absolutely not a wholesale replacement, and its inner workings are vastly different to Node. Edit: Well, someone touched a nerve! Doubt me, downvoters? You need but google to find a wealth of information to support the statement. https://www.imaginarycloud.com/blog/deno-vs-node/ is the first result, and there are a litany of other articles explai…
> Please stop spreading this misnomer. That's a fairly… direct way of putting it :-) Anyway: 1. What are the key differences in terms of usage and use cases? 2. Why isn't Deno a 'wholesale' replacement for Node? 3. In which respect are the vastly differently inner workings relevant in regards to usage of both products?
I’m curious about the value of eslint for TypeScript. I’ve not really found myself wanting from the coverage provided by tsc.
IDE integration is one benefit, as in VS Code showing the linting issues without compiling.
I’m curious about the value of eslint for TypeScript. I’ve not really found myself wanting from the coverage provided by tsc.
Mostly helpful to keep a shared ruleset across projects.
Earlier quoted context omitted.
No it's a replacement for Node.
Please stop spreading this misnomer. It's an alternative platform. It's absolutely not a wholesale replacement, and its inner workings are vastly different to Node. Edit: Well, someone touched a nerve! Doubt me, downvoters? You need but google to find a wealth of information to support the statement. https://www.imaginarycloud.com/blog/deno-vs-node/ is the first result, and there are a litany of other articles explai…
I’m curious about the value of eslint for TypeScript. I’ve not really found myself wanting from the coverage provided by tsc.
Generally, linting is things that are valid in the language, but still better to do otherwise.
Casting window to any in a pinch does work. But for longer term stuff, it's probably better to extend the Window interface.
I’m curious about the value of eslint for TypeScript. I’ve not really found myself wanting from the coverage provided by tsc.
Linting is not the same as typechecking. Take a look at the default available rules [1]. For example number == NaN is valid Javascript, but 99.9% of the time an error. Or you might want to require always using === over ==. Generally, linting is things that are valid in the language, but still better to do otherwise. [1] https://eslint.org/docs/rules/
In 2021, I think it's safe to start a TypeScript project with Deno.
Doesn't that depend on what libraries you need?
If there is a Node-specific library, i.e. a lib that uses the require global, the fs module, etc., then you can, in many cases, use the Node compat module from the Deno std lib and just drop it into your project.
That being said, there's of course a Deno-specific ecosystem of libs, too, i.e. libs that use the Deno global. So you might find a suitable replacement if your favorite Node lib is not compatible for some reason.