Copying what I wrote for [PR#1253](https://github.com/starknet-io/starknet.js/pull/1253#issuecomment-2452016503) about using spread `Calldata` as the argument so we can keep it in mind for this PR:

[tabaktoni]

          Copying what I wrote for [PR#1253](https://github.com/starknet-io/starknet.js/pull/1253#issuecomment-2452016503) about using spread `Calldata` as the argument so we can keep it in mind for this PR:

I believe the spread Calldata branch can also be removed ([...Calldata] | [...Calldata, ContractOptions] from the reworked ArgsOrCalldataWithOptions type). It is supported by splitArgsAndOptions itself, however, splitArgsAndOptions is in all its usages followed by the getCalldata() utility that filters the argument based on the __compiled__ marker which isn't propagated if the Calldata is spread. This means that the only spread input that should be able to work is method(...Calldata, { parseRequest: false }).

I don't see any utility in restoring the full support, so refactoring the code to exclude the supported scenario seems preferable, it should also simplify detecting whether a ContractOptions object is used.

The point made about the spread being filtered out later in the code execution still applies so the only supported scenario, updated for the changes from this PR, is the following:

  contract
    .withOptions({ parseRequest: false })
    .method(...Calldata)

An option is to keep it as is, but in that case we should probably clarify the behaviour in the documentation.

Originally posted by @penovicp in #1255 (comment)