Import Standard rules

[kecrily]

The idea is to resolve pointless code style arguments, the diversity of code styles does not make as much sense as the diversity of ideas. It brings nothing but pointless arguments, and instead of improving our development speed, it may waste time in determining the style of the code.

In this case, it clearly makes sense to establish a useful and common code style, then force it to be used. This may cause pain for a while, but it's worth it. There are languages that are ahead of the curve, such as Golang. This has also led to it receiving many positive reviews.

Free programmers from the prison of using different code styles for different projects and focus on the code itself.

As a code style guide with a popular base among TypeScript and JavaScript programmers, and it seems to me that Deno is a good fit for importing it.

---

• Specific rules of Standard

[magurotuna]

I agree that forcing developers to use the same and opinionated code style makes much more sense. And I believe Deno's philosophy also follows this idea.

In fact, Deno ships with the bulit-in code formatter deno fmt. This formatter is not configurable right now, forcing developers to use the opinionated code style. By doing this, developers don't need to care about code style. All they have to do is follow the formatter.

deno lint is designed to do static analysis on codebase to find out erroneous or buggy piece of code before actually running it. That is, basically the linter is not responsible for code style.

[bartlomieju]

I agree with @magurotuna plus Standard has come questionable conventions. We're quite happy with current status of deno fmt and deno lint so respectfully declining the request.

[kecrily]

In fact, Deno ships with the bulit-in code formatter deno fmt. This formatter is not configurable right now, forcing developers to use the opinionated code style. By doing this, developers don't need to care about code style. All they have to do is follow the formatter.

But in Roadmap I have seen plans to customize the enable/disable rules.

basic configuration - need ability to enable/disable rules for project. (#176)

In addition, this issue is mainly about importing Standard rules, and the unified code style is just a derivative of my plan based on what is listed in Roadmap and the concept of Standard.

This may be a difference in understanding caused by my lack of clarity in expression.

What I mean is that Standard has richer, more detailed rules, and we can pick and choose from them to further tighten the code style.

[magurotuna]

@kecrily
Yes there's a plan to provide configuration on which rules are run, and I think we're open to add new lint rules if they are useful in some aspects.
If you would like some of lint rules from the JS Standard, please open a proposal issue (like #779) and let's discuss whether that rule should be implemented in deno_lint. I think it'd be better to discuss one by one than the entire JS Standard.