wyze/eslint-plugin-wyze

My personal ESLint rules.

Neil Kistner (wyze)

eslint-plugin-wyze's Issues

Add `func-call-arg-spacing` rule

Working with --fix command

The Destructing key sort order is not working with '--fix' command.

It is a supporting future feature or will it not be implemented?

Or is it that i am not doing something correctly?

Thanks

Spike: `no-newline-beginning` rule

Research ability to add new rule similar to eol-last. Rule would ensure that there is no newline at the beginning of the file and code starts on the first line.

Alphabetically sort destructured arguments

`sort-destructuring-keys` throws an error when used with spread syntax

Summary

When enabling the sort-destructuring-keys rule, an error is thrown when it is used with the spread syntax.

Example

The following code de-structures the same object twice; once like normal, and once whilst also using the spread syntax.

const exampleObject = { a: 1, b: 2, c: 3, x: 24, y: 25, z: 26 }

const { a, b, c } = exampleObject
console.log(a, b, c) // 1 2 3

const { x, y, z, ...rest } = exampleObject
console.log(x, y, z) // 24 25 26
console.log(rest) // { a: 1, b: 2, c: 3, d: 4 }

With the rule 'wyze/sort-destructuring-keys': 2,, the above code will crash with the following error:

TypeError: Cannot read property 'name' of undefined
Occurred while linting /path/to/file/example.js:6
    at getKeyName (/example/node_modules/eslint-plugin-wyze/lib/rules/sort-destructuring-keys.js:57:76)

With the rule 'wyze/sort-destructuring-keys': 0,, the above code lints the file correctly.

Potential Fix

It appears the issue is because ExperimentalRestProperty is now referred to as RestElement which was a breaking changing in babel-eslint v11: Breaking changes in v11.x.x.

The following change is a quick fix, but I can I see a few other places in the code which is using ExperimentalRestProperty.

const getKeyName = node =>
-  node.type === 'ExperimentalRestProperty' ? node.argument.name : node.key.name
+ ['ExperimentalRestProperty', 'RestElement'].includes(node.type) ? node.argument.name : node.key.name

An alternative fix could be to replace all three instances of "ExperimentalRestProperty" with "RestElement" and release a new major version.

Spike: `max-file-length` rule

Check to see if we can get the number of lines in a file. Can get messy with large files. If possible, would like the default setting to be 200 lines.

Space around function arguments

Release needed for newest update

master !== npm.

Add `newline-after-export` rule

Similar to newline-after-var rule.

Bug in `space-around-conditional` rule

Version: 1.2.1

Code:

for ( ;; ) { /* ... */ }

Error:

Cannot read property 'end' of null

TypeError: Cannot read property 'end' of null
    at noSpaceAdjacentParen (/Users/nkist/Projects/velocity-navmenu-ui/node_modules/eslint-plugin-wyze/lib/rules/space-around-conditional.js:41:38)

Cut release with #24

Can you please cut a release with the updates from #24?

Unpin ESLint from ~2.2.0

Once eslint/eslint#5476 is resolved.

Spike: `max-func-length` rule

Ability to configure amount of lines in a function. Would set default to 20 lines.

Feature rest operator

Hey, is there a way to use the rest operator on an object with the wyze/sort-destructuring-keys rule without an error/warning?

const { x, y, z, ...rest } = this.props;

sort-imports with --fix causing broken code

Example imports:

import filter from 'lodash/filter'
import indexOf from 'lodash/indexOf'

After running with fix:

import filter from 'lodash/filter'cimport indexOf from 'lodash/indexOf'

It appears to be replacing the newline character with a c, but I've had other examples where it replaced the newline with i or even l

Bug exists in versions 3.2.1 and 3.2.0. I've reverted to 3.1.0 in the mean time.

`sort-imports` autofix incorrect with typescript-eslint-parser

The problem lies in what is returned in AST Nodes from typescript-eslint-parser when the fixer is trying to find the delimiter between declarations or specifiers when re-ordering them:

https://github.com/wyze/eslint-plugin-wyze/blob/master/lib/rules/sort-imports.js#L49-L50
https://github.com/wyze/eslint-plugin-wyze/blob/master/lib/rules/sort-imports.js#L60-L61

How To Fix It

The typescript parser apparently does not return start and end values on the node itself, instead requiring us to use range[0] and range[1]. If I replace the above referenced lines' references to .start and .end with .range[0] and .range[1] respectively, then the issue is resolved.

How To Fix It

I have a fix and want to figure out exactly how you'd like me to handle it. I see two options:

1. I just fix the code. Nothing changes, all tests pass.

   This provides no detectability because the tests already pass and will pass if this change is reverted, even though this won't work with typescript. If you don't use typescript, then you probably don't care :)

2. I fix the code and add a test that uses typescript-eslint-parser. This requires installing a devDependency of typescript-eslint-parser and it's peerDependency of typescript. I can then write a test that uses the typescript parser. I've done this in development; writing tests that fail before the above mentioned fix and pass after. All remaining tests continue to behave the same.

Let me know which you'd prefer and I'll send the PR. I'm going to optimistically assume you want version #2 and submit a PR.

Long Version: Why This Hurts

This results in the delimiter coming back as undefined and the two declarations being merged. This manifests itself in two ways, depending if it's a declaration or a specifier:

import B from 'b';
import A from 'a';

will autofix to the following:

import A from 'a';import B from 'b';

That will most likely be cleaned up by another rule, not causing any real issues. If there is no semicolon ;, then this will cause a hard failure in the resulting fixed code.

import B from 'b'
import A from 'a'

will autofix to the following:

import A from 'a'import B from 'b'

Second, using a specifier will cause the same issue, but will be much more insidious because it'll be removing whitespace from between to specifiers:

import {b, a} from 'a';

will be fixed to:

import {ab} from 'a';

Bug: destructuring over 10 keys in correct order gives error/ warning

Hey I'm trying to use wyze/sort-destructuring-keys lint rule in ascending order, any ideas why when I destructure over 10 keys a lint error/ warning is given?

I've tried it with both ascending and descending ordering, they both have the same issue.

Example:

const props = { a: 1, b: 2, c: 3, d: 4, e: 5, f: 6, g: 7, h: 8, i: 9, j: 10, k: 11 }

const { a, b, c, d, e, f, g, h, i, j, k } = props;

Errors:

[eslint] Destructuring keys should be sorted in ascending order. 'a' should be before 'g'. (wyze/sort-destructuring-keys)
[eslint] Destructuring keys should be sorted in ascending order. 'a' should be before 'c'. (wyze/sort-destructuring-keys)
[eslint] Destructuring keys should be sorted in ascending order. 'a' should be before 'd'. (wyze/sort-destructuring-keys)
[eslint] Destructuring keys should be sorted in ascending order. 'a' should be before 'e'. (wyze/sort-destructuring-keys)
[eslint] Destructuring keys should be sorted in ascending order. 'a' should be before 'b'. (wyze/sort-destructuring-keys)
[eslint] Destructuring keys should be sorted in ascending order. 'a' should be before 'h'. (wyze/sort-destructuring-keys)
[eslint] Destructuring keys should be sorted in ascending order. 'a' should be before 'i'. (wyze/sort-destructuring-keys)
[eslint] Destructuring keys should be sorted in ascending order. 'a' should be before 'j'. (wyze/sort-destructuring-keys)

By removing one key when destructuring the errors are fixed.

const props = { a: 1, b: 2, c: 3, d: 4, e: 5, f: 6, g: 7, h: 8, i: 9, j: 10, k: 11 }

const { a, b, c, d, e, f, g, h, i, j } = props;

Better Property.value consumption in sort-destructuring-keys

Hey!
First of all, thank you for sharing your plugin. Quite a few rules are really useful in daily use case.
There is a minor flaw in the current implementation of sort-destructuring-keys rule though, though.
Such patterns are unsupported at the moment:

const props = { a: 1, b: 2 }
const { b, a = b } = props

const props = { a: 1, B: 2 }
const { z, b = z, a = z + b } = props

const { z, c = 10, a = z() + c } = { z: () => 2 };

const { b, a = (c = b) => c } = { b : 2 }

Basically, we could take nodes with type AssignmentPattern into consideration.
We would just list all keys from Identifiers located in valid nodes such as ConditionalExpression, BinaryExpression, CallExpression, ArrowFunctionExpression, FunctionExpression etc.
Next step would be to filter these keys and pick only the ones that are found within ObjectPattern.
Once that is done, we could use them in sorting function.
I would be more than happy to give it a shot, since it's something I am missing and would use in my projects.
What do you think about that? Do we want to support such a case?
If so, I will proceed with actual implementation.
Cheers.