I am hoping to see ESLint rules such as
comma-dangle (trailing commas) be usable within an Atom package not merely to report violations after the fact, nor even to merely fix on save, but to immediately set the cursor to the proper indent upon adding a line break (for
indent) and to add trailing commas automatically when creating a line break (only when the project’s
comma-dangle rule calls for them or the user wishes them as a default).
When working in trailing-comma enforcing projects, it can be troublesome to have to add a comma after each array/object/function parameter addition and line break.
Even if there is a linter fix available, it is nice to have this set beforehand so that Atom’s linter doesn’t irritate one in showing errors.
Though there are some tools which auto-lint upon file-save, besides this being too delayed, some of us find it too dangerous to auto-enable all linting rule fixers when buggy or overly aggressive fixers can corrupt the code, potentially going unnoticed if one is not careful reviewing before adding to version control).
Trailing comma usage has become popular, especially as JS has increased its support (e.g., in function parameters). Even for those of us who don’t like it, when working on such projects, we don’t want to have to go through hoops, change our editor, etc., to deal with them.
However, while editing in Atom, there has been no way to configure this (AFAIAA), no less on a project-aware basis.
Similarly for indentation–it is too cumbersome to switch settings for every project, and
.editorconfig has its limitations as per the next section.
As far as 3rd party packages, such as EditorConfig / https://github.com/sindresorhus/atom-editorconfig , this proposal differs from current
.editorconfig behavior which has generally been more language agnostic. This proposal would also have these advantages over adding to
.editorconfig (if they were even open to it):
- It would not require a file redundant to one’s ESLint config.
.editorconfig), given that one may value readability over terseness more in docs than in code.
The behavior I’m seeking doesn’t seem to quite fit into the behavior of linters (at least as currently used), but in filing this concern with
Any suggestions on existing packages which might be willing to take this on and/or whether core could provide APIs to facilitate this?