NullVoxPopuli / eslint-plugin-decorator-position

ESLint plugin for enforcing decorator position

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Possible to define that multiple decorators should always be on different lines?

lougreenwood opened this issue · comments

We would like to stack multiple lines of decorators, e.g:

//example may not be legit
@memo
@task
thingy = ...

However, it seems that this isn't possible with the lint against with the linters current capabilities?

What sorts of things would you like to protect against with multiple decorators?

I'm open to supporting them in some way

like, is this possible: @memo @task thing = ... (I've never tried inlining multiple decorators)

maybe this rule would be called:

decorator-position/multiple-decorators: 'error' I see no reason why there'd be another way to organize multiple decorators

At the moment, the only use case I can think of would be to optionally define that inline is invalid, and multiple lines is valid:

bad 1:

@memo @task thing = ...

bad 2:

@memo @task
thing = ...

good:

@memo
@task
thingy = ...

obviously, ideally it would be possible to define any one of those variations as valid 😉

ideally it would be possible to define any one of those variations as valid

would it? lol. does anyone actually want multiple inline decorators?

would it? lol. does anyone actually want multiple inline decorators?

Subjectively speaking, no.

My thinking was that if this rule were to be added, it shouldn't be at the expense of not being able to disable it (where "disabling" means allowing either of the inline formats, since it seems that there are only 3 valid variations).

But I guess if people really don't like multiple inline (i.e either of the bad formats I suggested here), then it's not necessary.

(Side note, I hadn't properly considered the "bad 2" option before, but after seeing it in my examples I'm now a little bit curious about it.... :D)

it shouldn't be at the expense of not being able to disable it

Of for sure. Since this'd be a new rule, a person would set it to 'off' or 'warn' or whichever.

At least for the first iteration, I think it'll be easy to either enforce and fix a stack, or not at all. Later on down the road, a config could be added for other things.

it turns out that this:

@memo @task
thing = ...

is converted to

@memo 
@task
thing = ...

when using prettier

Closing, as this is handled by prettier, and I don't think that we need to duplicate the behavior?
Though, if someone has a good argument for re-implementing this, I'd be open to a PR or something :)