Adopt eslint-config-standard-with-typescript

[mightyiam]

I've been working on eslint-config-standard-with-typescript alone. It would be nice to have it adopted by the standard org and have some cooperation on it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mightyiam]

👅

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[LinusU]

Hey, sorry that no one has responded to you. I would be happy to help you transition the package and help maintain it as well 🙌

[mightyiam]

What do we do?

[LinusU]

Saw that you invited me, I'll try and move it here 🙌

[LinusU]

ah, I cannot do that, but I think that you can initiate a transfer, and then I can accept it on our side

[mightyiam]

"You don’t have the permission to create repositories on standard" when trying to transfer it to the standard organization.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mightyiam]

Try adding me to the standard organization?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[mightyiam]

I'm totally up for this to be adopted by @standard.

[PascalAOMS]

Maybe it progresses a bit faster if I leave a comment here. /shrug

[mightyiam]

@PascalAOMS the comment is in response to the stale bot adding the stale label.

I am still actively maintaining this package. And I've just updated it with all the breaking changes from upstream https://github.com/typescript-eslint/typescript-eslint/.

[LinusU]

Sorry for the delay here, I think that @feross or someone else that is owner on the standard reop will need to fix this 😬 unfortunately I don't have the permissions to fix this

[mightyiam]

🎺

[despian]

+1 would love to see this integrated into standard

[bjufre]

Any news on this?

[swansontec]

I tried using eslint-config-standard-with-typescript, but found that the rules are much stricter than I would have expected. For instance, it requires every function to declare its return type, even though Typescript is perfectly capable of inferring this. It also enforces the number[] array style over Array<number>, even thought the later is perfectly valid. There are many more examples of things like this.

The beautiful thing about Standard.js is that it focuses on finding actual bugs, and gets "out of the way" for everything else (aside from formatting). Requiring number[] over Array<number> doesn't have any clear bug-fighting benefit, for example, which makes it very out-of-character for a Standard.js variant (and it's a real syntax difference, not just a whitespace issue).

I understand that eslint-config-standard-with-typescript is derived from the @typescript-eslint/eslint-plugin recommended preset. Unfortunately, that preset has a rather aggressive "everything but the kitchen sink" approach to enabling linting rules. I do want to see Typescript support enter the Standard.js ecosystem, but it needs to take the same conservative approach that Standard.js takes, only enabling rules where there is a clear benefit to doing so.

[mightyiam]

@swansontec, thank you for giving it a try.

I welcome participation. Let's discuss all of the issues that you care about in the project's own issue tracker.

[LinusU]

It also enforces the number[] array style over Array, even thought the later is perfectly valid.

I personally think that this is great. There are two ways of doing something, and the enforced style is the one I've seen most in the wild.

I don't think that Standard "focuses on finding actual bugs, and gets "out of the way" for everything else", e.g. we do enforce a lot of white-space things, indentation and no semicolons.

Enforcing style as well as helping finding bugs helps keeps the code base uniform and helps readability, especially when there are multiple maintainers working on the code. For me, this is one of the awesome things about Standard ☺️

[feross]

Sorry for the delay on this. Still catching up on issues.

@LinusU I'm happy to help transfer this package to the @standard organization as long as you're involved in the maintenance and direction of the rules, to help out @mightyiam. I'm not using Typescript in too many places yet so I won't be able to chime in with my patented Taste as a Service™️. If something's living in the @standard org then it should follow a similar ethos and vibe. I haven't looked at the current set of rules in eslint-config-standard-with-typescript. It would be good to confirm that they're not too far off-base before we go ahead with this plan.

If it goes well, we might be able to build TypeScript support into the main standard binary by default so it just works on TypeScript projects too. That would be neat.

@LinusU Lmk if this plan sounds good to you and we can go ahead and figure out how to do the transfer with @mightyiam

[mightyiam]

Thank you for getting around to address this, @feross.

I did my best to follow the ethos and vibe of Standard, while also attempting to make as many decisions as I could reasonably make.

My desire from the get go was for it to become a part of @standard and I accept whatever that would mean in regards to ownership and control.

Looking forward to cooperate.

[feross]

I did my best to follow the ethos and vibe of Standard, while also attempting to make as many decisions as I could reasonably make.

Great! Looking forward to collaborating on this. Let's wait to hear what @LinusU says.

[LinusU]

If it goes well, we might be able to build TypeScript support into the main standard binary by default so it just works on TypeScript projects too. That would be neat.

😍 😍 😍

@LinusU I'm happy to help transfer this package to the @standard organization as long as you're involved in the maintenance and direction of the rules, to help out @mightyiam.

I think it sounds good, I'm happy to be involved in the maintenance and direction of the rules 👍

[mightyiam]

Lovely.

Would we like to make some changes before transferring it to @standard?

I'm referring to anything that might be non-representative of @standard that we might like to change.

[feross]

We can just do the transfer now. I trust that you and @LinusU will figure things out as you develop it here.

@mightyiam I just sent you an invite to the @standard organization. Can you try transferring the repo here now? I am unable to transfer your personal repo.

[LinusU]

Would we like to make some changes before transferring it to @standard?

I've been using it for a long time and have never seen something that I've considered non-standard ☺️

[mightyiam]

Transferred 🎉

I remember something about this org having a policy of all issues in this particular repo. Is that still the case, please?

[feross]

I think that until we're ready to support Typescript in standard (if we decide it's a good idea) then it would be better to keep the issues separate for now. I think it will be easier to see all Typescript related issues in eslint-config-standard-with-typescript to avoid confusion for now.

[swansontec]

@LinusU @mightyiam Thanks, I'll go ahead and create issues in that repo, then.

Since the number of "extra rules" in eslint-config-standard-with-typescript surprised me, I actually created my own competing project, eslint-config-standard-kit, which creates a one-stop solution for mixing & matching Standard.js with Flow, Typescript, JSX, and / or Prettier.

Since it looks like eslint-config-standard-with-typescript is becoming the semi-official Standard.js + Typescript solution going forward, I would like to collaborate on bringing eslint-config-standard-kit in sync with its rules, especially the auto-fixable ones. Here is my issue for tracking the necessary changes.

[feross]

@swansontec The work you've done to separate all the rules into separate packs is excellent! I'd love to see how we could adopt that directly here eventually. In the meantime, I want to get a few more releases out. But this would be great to offer to users right out of the box!

[ndom91]

+1 would love "rule packs" like that, but out of the box typescript support is much higher on mine (and I'm assuming many others) lists :)

Edit: By the way, I'm wanting to use standard on a react typescript project, using standard via vscode. If I can do anything to help test, etc. just let me know!