Why a Next.js project has over 30 configuration files and what we can do to avoid it.

Deno's official blog provides updates, tutorials, and use cases for Deno, a secure JavaScript/TypeScript runtime. Developers can explore Deno's features, security model, and ecosystem integrations, gaining insights into modern JavaScript development practices. With contributions from Deno core contributors and community members, the blog offers resources for developers adopting Deno for their projects.

Deno

Config Hell is a way to set up the projects, tools, plugins, and software you’re using. All software requires configuration, but with smart defaults, all users have slightly different needs. Asking users to configure software before they can use it can damage goodwill and trust users.

Node.js's Config Hell Problem

The JavaScript ecosystem is (mostly) unopinionated

The only thing this article shows that deno support typescript by default, then what?

I don’t get it, Is the solution for config hell problem is using DENO?

This is a viewpoint, but it is not easy to evaluate.
There’s nothing wrong with marketing Deno, but if the necessity of Deno is always raised by attacking (maybe not) or downgrading existing tools (or factual standard), this is likely to lead to some developers being resistant and perceiving Deno’s marketing as offensive, which makes it difficult to create a moderate, positive opinion in the community.
A recommended approach would be to elaborate on how Deno solves this problem, such as the design philosophies Deno promotes and how Deno allows developers to extend and add configurations in edge scenarios, and I think developers will vote with their feet if Deno show enough of the benefits and the elegance.
Not just for this post, this is how I feel about reading Deno’s marketing posts lately.