Planned large or breaking changes for v7.0

[JoshuaKGoldberg]

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

💪 Large changes

• Use the same processes to generate documentation as TSLint core #575: Use the same processes to generate documentation as TSLint core

⚠️ Breaking changes

• Use in-place compilation instead of directory swapping #825: Use in-place compilation instead of directory swapping
• Stop including library-specific rules in the recommended ruleset #716: Stop including library-specific rules in the recommended ruleset
• Ease up on strictness in the default configs of naming rules #678: Ease up on strictness in the default configs of naming rules
• Stop extending from TSLint's ruleset in the published ruleset #677: Stop including TSLint core rules (followup to Publish a 2nd recommended ruleset that contains *only* the contrib rules #309, which can come in first)
• Remove SDL hooks metadata and build steps #611: Removal of SDL hooks metadata and build steps
• Remove our custom fix formatters #577: Removal of custom fix formatters
• Generalize Mocha rules to all testing frameworks #455: Generalize Mocha rules to all testing frameworks
• Removal of rules deprecated before 6.0

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

[JoshuaKGoldberg]

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

[IllusionMH]

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

[astorije]

@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]

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

[JoshuaKGoldberg]

@astorije - agreed; added to the list:

• Stop extending from TSLint's ruleset in the published ruleset #677: stop including TSLint core rules (followup to Publish a 2nd recommended ruleset that contains *only* the contrib rules #309, which can come in first)
• Ease up on strictness in the default configs of naming rules #678: removal of that odd casing preference

[reduckted]

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]

#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]

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]

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]

This project is read-only and archive mode.