Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

Planned large or breaking changes for v7.0 #672

Closed
JoshuaKGoldberg opened this issue Dec 13, 2018 · 10 comments
Closed

Planned large or breaking changes for v7.0 #672

JoshuaKGoldberg opened this issue Dec 13, 2018 · 10 comments
Labels
Domain: Tooling Repository tasks around improving source tooling. Status: In Discussion Please continue discussing the proposed change before sending a pull request. Type: Breaking Change Type: Question

Comments

@JoshuaKGoldberg
Copy link

JoshuaKGoldberg commented Dec 13, 2018

Starting this discussion early to track what's going to be in 7.0... what else should go here?

💪 Large changes

⚠️ Breaking changes

Note that 7.0 won't happen for quite some time (and should have a beta version first, per #645).

@JoshuaKGoldberg JoshuaKGoldberg added Type: Question Status: In Discussion Please continue discussing the proposed change before sending a pull request. Domain: Tooling Repository tasks around improving source tooling. labels Dec 13, 2018
@JoshuaKGoldberg
Copy link
Author

JoshuaKGoldberg commented Dec 13, 2018

/cc @IllusionMH, @HamletDRC, @astorije if you have any preferences 🙂

@IllusionMH
Copy link
Contributor

Posted some thoughts about no-octal-literals here: #653 (comment)
If it will be preferred way - deprecation/removal should be tracked here.

@astorije
Copy link
Contributor

@JoshuaKGoldberg, I don't know if this is the type of feedback you are looking for, but I would love it if function-name was not forcing me to use all uppercase to name my static functions here.

So without disabling this rule, this is what I would have to do at the moment:

class Thing {
  constructor(ast: Ast) {
    // ...
  }

  static PARSE(sql: string) {
    return new Thing(parser.parse(sql));
  }
}

// Use it with:
Thing.PARSE('SELECT * from foo');

Instead I'd prefer to name it parse and call it with Thing.parse('SELECT * from foo');. I find that more in line with things like JSON.parse(), Date.now(), etc.
I also find that to be a lot more common out there than all uppercase.

@JoshuaKGoldberg
Copy link
Author

A few more people: @reduckted @mesaugat @iclanton, any thoughts on things you'd like to see here for 7.0?

@JoshuaKGoldberg
Copy link
Author

@astorije - agreed; added to the list:

@reduckted
Copy link
Contributor

Regarding function-name, I don't use it and instead use the naming-convention rule from tslint-consistent-codestyle. It's highly configurable and looks at things like access modifiers and whether things are exported or not.

@reduckted
Copy link
Contributor

#586 talks about changing the new rule template to use a walk function instead of extending AbstractRule. I imagine that all existing rules should be changed to use a walk function as well. That would be a pretty large change, so it might be a good candidate for 7.0.

@JoshuaKGoldberg
Copy link
Author

all existing rules should be changed to use a walk function

Yes! Though we can do that before 7.0 as it's not a breaking function. Filed an issue here: #680

@reduckted
Copy link
Contributor

Not sure if this will affect v7 of this package, but you may want to check out the TypeScript Roadmap regarding linting, because it seems to have an impact on TSLint.

microsoft/TypeScript#29288

Since part of our team is dedicated to editing experiences in JavaScript, our editor team set out to add support for both TSLint and ESLint. However, we noticed that there were a few architectural issues with the way TSLint rules operate that impacted performance.

...snip...

Given this, our editor team will be focusing on leveraging ESLint rather than duplicating work. For scenarios that ESLint currently doesn't cover (e.g. semantic linting or program-wide linting), we'll be working on sending contributions to bring ESLint's TypeScript support to parity with TSLint. As an initial testbed of how this works in practice, we'll be switching the TypeScript repository over to using ESLint, and sending any new rules upstream.

@brndkfr
Copy link
Contributor

brndkfr commented Dec 10, 2020

This project is read-only and archive mode.

@brndkfr brndkfr closed this as completed Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Domain: Tooling Repository tasks around improving source tooling. Status: In Discussion Please continue discussing the proposed change before sending a pull request. Type: Breaking Change Type: Question
Projects
None yet
Development

No branches or pull requests

5 participants