Rule: keep-options-order

[Kelin2025]

Story

For now, we can write sample/guard in any order:

sample({
  target: foo, 
  fn: (bar) => Baz, 
  source: bar, 
  clock: clock
}) 

Would be nice to enforce a more convenient order
E.g. source->clock->fn->target (or clock first)

Extra stuff

• We also need the same thing for @sergeysova patronum I guess

[igorkamyshev]

In my opinion, clock->source->fn->target is better because clock is primary.

[doasync]

@igorkamyshev it's not better, it's just a different opinion. The first param in fn is source... then goes clock. I think, there should be an option to choose.

[igorkamyshev]

I disagree. Linter should give your consistency, not options.

[sergeysova]

Also, it should autofix

[doasync]

@igorkamyshev Why not use the order of fn params?

What should be the order of guard options?

Linter should give your consistency, not options.

Linter can give options, you can use default ones for consistency. Or do you want to force your opinion without a choice?

It's good for maintainer to discuss with the community before making such a decision.

[sergeysova]

I like the natural order of options: just like you read it.

sample({ source, clock, fn, target })
When clock is triggered, read data from source, pass it thru fn, and sent to target

As we see, order is clock, source, fn, target

---

The same for guard

guard({ clock, source, filter, target })

When clock is triggered, check filter for truthy, read data from source, send it to target.
Order is: clock, filter, source, target.

[doasync]

Yeah, I understand your point. It seems good as the default order. I could get used to that.

But you both ignore the fact that source data comes before clock data in the fn parameters. Many people are used to this alternative order. Why are you sure that the option is unacceptable here?