noAssignInExpressions: please don't flag in arrow expressions

[ysageev]

Environment information

CLI:
  Version:                      12.1.0
  Color support:                true

Platform:
  CPU Architecture:             x86_64
  OS:                           windows

Environment:
  ROME_LOG_DIR:                 unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v18.12.1"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "npm/9.6.6"

Rome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              false
  Organize imports disabled:    true
  VCS disabled:                 true

Workspace:
  Open Documents:               0

Discovering running Rome servers...

Running Rome Server: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

i The client isn't connected to any server but rage discovered this running Rome server.

Server:
  Version:                      12.1.0
  Name:                         rome_lsp
  CPU Architecture:             x86_64
  OS:                           windows

Workspace:
  Open Documents:               0

Other Active Server Workspaces:

Workspace:
  Open Documents:               0
  Client Name:                  Visual Studio Code
  Client Version:               1.78.2

Workspace:
  Open Documents:               6
  Client Name:                  Visual Studio Code
  Client Version:               1.78.2

Workspace:
  Open Documents:               4
  Client Name:                  Visual Studio Code
  Client Version:               1.78.2

What happened?

I would like to be able to write one-line functions that are basically "procedures", for example:

const func=(e) => (e.foo="bar")

But this trips the lint rule noAssignInExpressions, so I have to rewrite it in 3 lines as

const func=(e) => {
    e.foo="bar"
}

I know this is whining, and I could always disable the rule, but does this have to be flagged?

Is return (a=b) really a problem?

Waaaaah!

Expected result

return (a=b) is OK

Code of Conduct

• I agree to follow Rome's Code of Conduct

[Conaclos]

Hi!

Your suggestion applies to both arrow expressions and return statements? or only arrow expressions?

In my view, the second code is cleaner and less confusing.
It clearly communicates your intent.

Your problem seems more related to the formatting.

[ysageev]

In the single line arrow expression, there is an implicit return.

[luluco250]

Maybe one way to fix this could be to require void before the the lambda assignment expression (like void (e.foo = "bar")), which would also prevent leaking the assignment as an implicit return.

[Conaclos]

We could revisit the formatting and allow inline arrow statements such as (e) => { e.foo = "bar" }.