Missing spaces around name interface and type

[valentineus]

Repository with example.

Instruction

1. Clone a repository:

git clone https://gitlab.com/valentineus/typescript-eslint-example.git

2. Install dependencies:

npm install

3. Run a test:

npm run lint

Code to check:

interface ITesstInterfase{
    key: string;
}

type TestType=() => void;

const variable1: TestType = () => {

    console.log("Hello, World!");

};

variable1();

Enabled all rules eslint and @typescript-eslint/eslint-plugin.

On line 1, missing spaces around interface ITesstInterfase.
On line 5, missing spaces around sign =.

Are there any rules governing such cases?

package	version
@typescript-eslint/eslint-plugin	2.19.2
@typescript-eslint/parser	2.19.2
eslint	6.8.0

[bradzacher]

There is not rules which cover either. Our general guidance is to not rely upon a linter for formatting, and instead you should use a tool made for formatting, like prettier.

That being said:

• type TestType=() => void; could be handled by an extended version of space-infix-ops.

• interface ITestInterface{ could be handled by an extended version of space-before-blocks

Happy to accept a PR.

[zanona]

Our general guidance is to not rely upon a linter for formatting, and instead you should use a tool made for formatting, like prettier.

Hey, @bradzacher, sorry about the off-topic here but referring to your comment, would you recommend anything besides prettier? Or better, does anything besides prettier exists to format code nowadays? The problem is that being 'opinionated' like prettier, doesn't allow for customisation at all. So there must be another solution. :)

[richardsimko]

Our general guidance is to not rely upon a linter for formatting, and instead you should use a tool made for formatting, like prettier.

Another question on this topic, there are plenty of rules regarding formatting, what's the reasoning behind including them in that case? (comma-spacing, indend, keword-spacing just to name a few)

[bradzacher]

To start with - a personal anecdote for you.

At the start of my career, I was all for tweaking and adjusting code style to match the team's style. I spent many hours configuring eslint (and other tools, like resharper for C#) to match the exact code style of our codebase. I did this for years across 5 or 6 codebases and 2 companies. But it was never quite right, there were edge cases that rules didn't catch, or cases that rules wouldn't enforce. It resulted in writing documents about style standards to help code reviewers catch incorrectly styled code. It was a large burden for everyone.

And then I started at facebook, where they enforce that all JS code across their ginormous monorepo is formatted using prettier, and have done so for many years. Initially I hated it - I am the engineer and I want to format my code in a certain way.

It only took me a week of using prettier to fall in love. No longer did I have to think about formatting. No longer did I have to think about indentation or brace placement. I just wrote code, hit save, and got a consistent code style.

When reviewing code I no longer had to look at the formatting or anything. I didn't have to keep an eye out for disabled formatting rules and question why. I just reviewed the code and thought about the logic.

It was a revelation - I went to all of my open source projects and I installed prettier and formatted the codebases, and I've never looked back.

Now-a-days I actually find I dislike working on codebases that don't use prettier now because those codebases are often inconsistently formatted. It's unpredictable and makes the code harder to read.

The moral of this story is to just try it - let go of the desire to control the styling and you'll find how much better your engineering life will be.

---

would you recommend anything besides prettier

🤷‍♂️ I've never used or wanted to use anything else. Prettier lists the prettierx project as a related "less opinionated" version of prettier. Never looked into it or used it however, so IDK if it's going to do what you want.

The problem is that being 'opinionated' like prettier, doesn't allow for customisation at all.

The reason that it doesn't allow for customisation is that customisation makes the codebase a maintenance nightmare. Case in point - the indent rule (#1824).

When you start adding options, people want more options. More options means more branches. More branches means exponentially more tests. It is a nightmare.

We see this problem within this project as well - some lint rules have ridiculous combinations of options and attempting to cover every use case leads to tests that are unapproachable and unmaintainable. For example this 3300 line monster test suite for the overly configurable member-delimited-style stylistic rule. The rule itself is only 239 lines, but it needs that much testing to cover every branch and case. It's straight up not worth it - nobody is ever going to be able to work on that rule ever again because the tests are so complicated.

Another question on this topic, there are plenty of rules regarding formatting, what's the reasoning behind including them in that case?

One reason really: people want them - engineers are opinionated AF and want to do things their way 😄

Earlier in my OSS "career", I was all for satisfying everyone - I personally implemented and enhanced extension rules for these stylistic rules, and I worked on new rules to help style TS code.

But since discovering prettier, I've gone in the other direction. I try to do as close to zero work on stylistic rules as I can now - I don't have enough time as it is to work on this project, so I don't want to (as I see it) waste my time on stylistic rules when I can instead work on higher value tasks like improving the core infra.

If contributors want to work on and implement or fix stylistic extension rules themselves, I'm not going to say no - I'll happily review the PRs and merge them. Extension rules I see as a bugfix instead - adding TS compatibility to the base rules, so blocking people working on them will ultimately negatively impact the ecosystem and detract from this project's value.

[zanona]

@bradzacher, thank you so much for taking the time to tell us your experience and how that influenced your way of thinking, making you a better professional. It's really great reading about this, as sometimes, we become too obsessed with a single way of solving problems and forget about other possibilities. Thanks again.

[richardsimko]

@bradzacher Thanks for the long and detailed reply! I'll make sure to give prettier a try ;)

[FDIM]

The issue related to space around type declaration is now fixed in the linked PR. Second issue with interface I'll address in a separate PR - it's a bit more work as space-before-blocks needs to be extended, yet to figure out how

[josephzidell]

@FDIM Have you had time to look at spacing around interface blocks?

[morganbarrett]

space-before-blocks should handle types before the open parenthesis when set to "never"
e.g function x(): number { vs function x(): number{
this could be an extra option for the extended version

[sbitenc]

When is this coming out? I need this :)

[bradzacher]

With any issue in opened in this project - it either has a visible progress in the form of an attached PR, or it has no progress.

We are a community run project. The volunteer maintainers spend most of their time triaging issues and reviewing PRs. This means that most issues will not progress unless a member of the community steps up and champions it.

If this issue is important to you - consider being that champion.

If not - please just subscribe to the issue and wait patiently.
Commenting asking for status updates does not bump issue priority in any way and just serves to spam everyone subscribed to the issue.