Running npx gatling run does not offer a TypeScript simulation you just added, so which folder and file-name pattern does the Gatling JavaScript CLI search, and how do you point it at a different folder?

The JavaScript/TypeScript SDK has no class names to select on, so the CLI finds a simulation by **convention over the filesystem**: a folder, a file-name pattern, and a module default export. Get any of the three wrong and the simulation simply is not offered — there is nothing to look up by name. ## The default layout | what | default location | option that moves it | |---|---|---| | simulation sources | `src` | `--sources-folder` | | resource files, e.g. feeder data | `resources` | `--resources-folder` | | HTML reports of a local run | `target/gatling` | `--results-folder` | | the code bundle the CLI builds | `target/bundle.js` | `--bundle-file` | ## The file-name rule, precisely The CLI finds simulations **defined in files named with a `.gatling.js` or `.gatling.ts` extension at the root of the sources folder**. Three details in that sentence do work: - **The suffix is doubled.** `checkout.gatling.ts` matches; `checkout.ts` does not, however correct its contents are. Gatling's own recorder writes these names — its JavaScript output format uses the file extension `gatling.js` and its TypeScript format `gatling.ts`. - **Both extensions are searched, always.** One SDK serves both languages, so the pattern is `*.gatling.js` *or* `*.gatling.ts`; you do not configure which language a project is in for discovery to work. - **At the root.** A file at `src/checkout/checkout.gatling.ts` is nested, not at the root of `src`, so it is not picked up. Helper modules may live in subfolders and be imported normally — only the simulation entry points must be flat. On top of the name, the file has to **default-export the value `simulation(...)` returns**. A file with the right name that exports its simulation under a name, or exports nothing, is matched by the pattern and then yields no simulation. ## Where the naming convention comes from The doubled extension is not a documentation flourish; it is baked into the tooling that writes these files. Gatling's recorder, which captures a browsing session and generates a starting simulation, emits its JavaScript output with the extension `gatling.js` and its TypeScript output with `gatling.ts` — the exact patterns the CLI later searches for. The same recorder marks its JVM output formats as having packages and its JavaScript and TypeScript formats as not, which is the other half of the story: with no package namespace, the folder-plus-file-name convention is the only identity a simulation has. ## Selecting one when several match `npx gatling run` with no further arguments discovers every match and, if there is more than one, **asks you to choose**. To skip the prompt, name the simulation: ```shell npx gatling run --simulation "checkout" ``` The value is the file's base name **with the `.gatling.js` / `.gatling.ts` suffix removed** — `checkout` for `src/checkout.gatling.ts`. It is not a JVM-style fully qualified class name, and not the file path with its extension. (Gatling Enterprise's own git-repository configuration uses the same convention for JavaScript projects: the test name, `demoSimulation`, for `demoSimulation.gatling.js`.) One JavaScript tutorial page does pass a path-shaped `--simulation src/basicSimulation.gatling`, so a value carrying a directory is not universally rejected — but the bare base name is the form every reference page documents, and it is the form to write. ## Running from a non-default sources folder This is the case worth rehearsing, because it combines both options. Suppose a repository keeps its performance tests in `perf/` rather than `src/`: ``` perf/ checkout.gatling.ts search.gatling.ts lib/ protocol.ts ``` ```shell npx gatling run --sources-folder "perf" --simulation "checkout" ``` `--sources-folder` redirects discovery, and `--simulation` disambiguates between the two matches inside it. `lib/protocol.ts` is not a simulation and is not meant to be — it is a helper module the two entry points import, and its position in a subfolder is exactly right. ## A checklist when a simulation is not listed 1. **Extension** — does the name end in `.gatling.ts` or `.gatling.js`, not just `.ts` or `.js`? 2. **Location** — is the file directly inside the sources folder, not in a subdirectory of it? 3. **Folder** — is that sources folder `src`, or did you pass `--sources-folder`? 4. **Export** — is the `simulation(...)` value the module's **default** export? 5. **Install** — did `npm install` actually run in this project, so the CLI and the packages the file imports are present? ## Why a rename is not a cosmetic change Because the file name *is* the simulation's identity, renaming a simulation file changes the value anything that selects it has to pass. Treat the base names of your `*.gatling.ts` files as a small published interface of the repository, and rename them as deliberately as you would rename a class.