In Gatling's JavaScript and TypeScript SDK, which feeders and feeder methods from the JVM SDKs are missing?

## How the docs signal the gap Gatling's documentation renders each concept page with one tab per language, and each tab is a region of a real sample file. Where a feature has no JavaScript equivalent, the JavaScript sample file does not omit the region — it defines the region and fills it with the literal text **`NOT SUPPORTED`**. So the JavaScript tab of the page renders those two words where the Java tab renders code. A few regions say it in a sentence instead — the custom-iterator one reads "The `feeder(Iterator)` method is currently not supported by Gatling JS." — so read the tab rather than grepping for the two words. This matters because the five-language framing is about the *authoring surface*, not about feature parity. A reader who checks only the Java tab never learns that a feature is missing, and a `coverageArea` or a blog post that names an identifier without qualifying the SDK is simply false in two of the five languages. ## What is missing on the feeders page | surface | status in the JavaScript and TypeScript SDK | |---|---| | `jdbcFeeder(url, user, password, sql)` | `NOT SUPPORTED` | | `redisFeeder(...)` with `LPOP` | `NOT SUPPORTED` | | `redisFeeder(...).SPOP()` | `NOT SUPPORTED` | | `redisFeeder(...).SRANDMEMBER()` | `NOT SUPPORTED` | | `redisFeeder(...).RPOPLPUSH()` | `NOT SUPPORTED` | | `readRecords()` | `NOT SUPPORTED` | | a feeder built from your own iterator | documented as not supported | The documentation page reinforces the `readRecords` case in its own markup: that section is declared to render only the Java, Kotlin and Scala tabs. ## What is present Almost everything else on the page: * the delimited family — `csv`, `tsv`, `ssv`, `separatedValues`; * `jsonFile` and `jsonUrl`; * `sitemap`, imported from `@gatling.io/http` rather than `@gatling.io/core`; * `arrayFeeder` for in-memory records; * the chained options `unzip()`, `shard()`, `transform(...)` and `recordsCount()`; * `feed(feeder)` and `feed(feeder, 2)`, including the expression and function forms of the count. The pairing worth remembering is **`recordsCount` survives and `readRecords` does not**: you can ask a JavaScript feeder how many records it holds, but you cannot ask it for them. ## The one asymmetry that catches people `recordsCount()` and `readRecords()` are declared on the same builder interface on the JVM, which makes it tempting to assume they travel together. They do not. A JavaScript simulation can ask a feeder how large it is and cannot ask it for its contents, so any JVM helper that materialised the records — to derive a lookup table, to split one file into two feeders, to assert something about the data before the run — has no direct translation and has to be rewritten around the file itself. ## Why the shape is what it is The JVM SDKs are two binding layers over one Scala core: a Scala DSL, and a Java API that Kotlin also consumes as-is. `jdbcFeeder` and `redisFeeder` are not core at all — they live in separate JDBC and Redis modules that pull in a JDBC `DriverManager` and a Redis client library respectively. The JavaScript and TypeScript SDK is a separately published npm package family, so a feature whose implementation is a JVM library dependency is exactly the kind of thing that does not cross over. `readRecords` is a smaller case of the same thing: it hands you the parsed records as JVM collections. Be careful how far you push this reasoning. The npm packages' own source is not something you can read alongside the Scala repository, so the honest statement is *the documented samples mark these as unsupported* — not a claim about what some npm build does at run time. ## What it means in practice The practical consequence is blunt: **a JavaScript or TypeScript Gatling simulation cannot source virtual-user data from a database or from Redis.** The data has to arrive some other way. 1. Export it before the run and ship it as a file under `resources`, then read it with `csv`, `separatedValues` or `jsonFile`. For a 200,000-row credentials file that is the natural answer anyway. 2. Build the records in the script and hand them to `arrayFeeder`, which is fine for tens or hundreds of rows and wasteful for hundreds of thousands. 3. Fetch a JSON array over HTTP at declaration time with `jsonUrl`, if a service can serve it. If you are choosing an SDK for a suite whose data genuinely lives in a database at run time, that alone can decide the question — and if you are porting an existing JVM suite, the feeders are the first place to look for something that will not come with it. The same `NOT SUPPORTED` pattern appears elsewhere in the docs, so check the JavaScript tab of any page whose identifier you are about to rely on rather than assuming parity.