Can you share a bit on the use case, i.e. what do you need configured?
Personally, I find Deno's "zero config" approach appealing, although I do have to fight the linter's "ban-types" rule occasionally since suggested type replacements are not equivalent.
> Personally, I find Deno's "zero config" approach appealing, although I do have to fight the linter's "ban-types" rule occasionally since suggested type replacements are not equivalent.
Precisely this. I'm compiling TS using `Deno.emit()`, which can be directly configured, but it would be nice to just configure Deno's linting/compiling behavior at the project level so that the same issues don't appear in VS Code with the Deno extension.
Thanks, I usually do, but in this case they are typescript issues and have tickets in the ts repo.
For example, constructor signature for mixins requires `any` type that conflicts with `no-explicit-any` rule. In another case, `object` cannot be replaced with `Record<string, unknown>` when used with conditional types to mean "any non-primitive value".
This comment right here is enough for me to become suddenly much less keen on Deno.
If you're somebody who wants to make their ts as close to provable as possible, but also be able to handle dynamic / generative content, then you run into issues of this nature all the time with (for example) linter settings that think they know typescript better than you do, but fail to recognize that there is literally no other way to express some type-concept in typescript without using a larger feature set.
I agree wholeheartedly with the argument: tools getting in a way is the ultimate annoyance; in fact, struggling to force Jest to play nicely with ESM modules and TypeScript was the final straw that pushed me towards Deno for library development.
However, the argument can be made against any tool, and I'd say Deno here is the least deserving: in most cases it has just adopted the "defaults" set by tsc, eslint, or prettier, and just like them it allows ignoring these rules where necessary.
That said, I also think Deno made the right choice by enforcing these by default. Hopefully, it will fight the tide of low-quality code that plagues NPM. I do have to wrestle the linter, but it's mostly because I'm writing libraries that by themselves are pushing the limits of the TS type system, e.g. in structurae[1] I make an extensive use of mixins extending built-in objects, and mixin support is still nascent in TS. This is far less common in day-to-day production code, where, for example, using `any` or `object` is more often a sign of sloppy thinking rather than a necessity.
You can use Deno without TS. I use it with plain JS and the code/test cycle is much faster without typescript compilation. Basically prefer Deno for ES6 modules and the good standard library.
