In Karate, how does `* karate.call('login.feature')` differ from the step `* call read('login.feature')`, and how do you get shared scope from the JavaScript form?

## Same job, opposite defaults Karate offers two ways to invoke another feature, and they disagree about scope: ```gherkin * call read('login.feature') # shared scope * def out = call read('login.feature') # isolated * karate.call('login.feature') # isolated, result thrown away * def out = karate.call('login.feature')# isolated, same as the second line * karate.call(true, 'login.feature') # shared scope, explicitly ``` The step form decides on the **presence of a result variable**. The JavaScript function has no such syntax to read, so it defaults to isolated and takes an explicit boolean when you want the other behaviour. Read together, the two defaults look inconsistent; read separately, each is the safe choice for its form. Either way, the fix for surprise is to know which form you typed. ## What the boolean actually does `karate.call(true, path)` runs the feature the same way, then walks the returned map and sets **every key as a variable in the calling scenario**. That is the same effect a bare `call` step produces, so a shared-scope helper behaves identically through either route. The signatures accepted are: - `karate.call(path)` - isolated - `karate.call(path, arg)` - isolated, with a call argument - `karate.call(true, path)` - shared - `karate.call(true, path, arg)` - shared, with a call argument Passing a boolean without a path is an error, so the two-argument form is never ambiguous. ## Why the JavaScript form exists A `call` step is a step: it always runs. The JavaScript form can sit inside an expression, which is what you need for conditional reuse: ```gherkin * if (env != 'local') karate.call(true, 'classpath:common/auth.feature') ``` Without the boolean that line would authenticate and then throw the session away - the single most common bug in conditional setup. It is also available anywhere JavaScript runs, including a function defined in the config chain, which a step keyword cannot reach. ## When each form reads better | Situation | Form to reach for | |---|---| | Unconditional shared setup in a `Background` | `* call read('setup.feature')` | | You want the answer under a name you chose | `* def out = call read('helper.feature')` | | The call has to be conditional and must share | `karate.call(true, path)` | | The call has to be conditional and is a function | `karate.call(path, arg)` | | Calling from inside a JavaScript helper | the `karate.call` form, necessarily | For everyday reuse the step forms read better in a feature file, and most suites should use them by default. Reach for `karate.call` when you genuinely need an expression. ## The argument, and the loop form Both routes take the same call argument and treat it the same way. A map is bound whole to the hidden `__arg` binding inside the callee **and** spread key by key as ordinary variables, so a helper invoked with `{ user: 'john' }` can write `* path 'users', user` directly. An array argument selects the loop form in either route: the feature runs once per element, `__loop` carries the zero-based index, and the collected results come back as a list rather than a map. ```gherkin * def rows = [{ n: 1 }, { n: 2 }] * def viaStep = call read('make.feature') rows * def viaJs = karate.call('make.feature', rows) ``` Both lines above run `make.feature` twice and produce a two-element list. The difference between the routes is never *what* runs - only whether the callee's variables are published into the caller afterwards. ## Things that stay the same either way Whichever form you use, the rest of the model is unchanged: - The callee sees the caller's variables - copies when isolated, the live map when shared. - The caller's configuration is copied down in both scopes. - The `karate-config.js` chain is not re-evaluated for the called feature. - An array argument still turns the call into one run per element, returning a list. - The hidden `__arg` and `__loop` bindings are still available inside the callee. ## Review guidance Treat a bare `karate.call(...)` whose result is discarded as a smell: either the author wanted shared scope and forgot the boolean, or the call is pure side effect on the callee's own state and deserves a comment saying so. A quick grep for the JavaScript form across a suite usually turns up one or two conditional setup lines that have been quietly doing nothing for months.