prefer-ternary: Refactor to use ESLint recommended way to extend fix range

[fisker]

ESLint recommended a new way to extend fix range.

[fisker]

@mdjermanovic After I tried the way you recommended, I figure I can simplify the logic to this 404860c

function * extendFixRange(range = []) {
	const [start = 0, end = Infinity] = range;
	yield {range: [start, start], text: ''};
	yield {range: [end, end], text: ''};
}

So, I don't need pass fixer to this function, do you think it's good?

[futpib]

I don't think it's good. { range, text } objects are not public API for ESLint.

[mdjermanovic]

ESLint recommended a new way to extend fix range.

It isn't official yet. The applying fixes spec was intentionally not too specific in order to allow for future internal optimizations. It's arguable whether eslint/eslint#13748 documents too many internal details and thus adds some implementation constraints that may not reach consensus.

Nevertheless, I'd say it's pretty safe to use this pattern, unlike requiring the FixTracker module which almost certainly won't make it into the public API when we add the exports field in v8.0.0 (eslint/eslint#13654).

[fisker]

@mdjermanovic

Thanks for the quick reply.

I'd say your suggestted implementation in eslint/eslint#13748 is very good, just two lines in fix function.

But I'm going to add this as a utility function, and I think most cases we need in our codebase is extend the range to the whole file, so yield * extendFixRange(fixer, context.getSourceCode().ast.range); still seems too complicated to use.

@futpib Do you insist to use public fixer api?

[fisker]

@mdjermanovic Thank you very much, I restored the changes.

[sindresorhus]

What's left for this to be mergable?

[fisker]

I don't think there is anything to do, unless you have a better idea to make it easier to use. We may need check other rules. when generating a new variable, should use this function to avoid conflicts with other rules(ours and other plugins).