CodeVetter · Repo Unpack · Extension points
lodash/lodash
The intended way to add a method is: implement it in `lodash.js`, attach it with `lodash.<name> = <name>` in the assignment block, add tests in `test/test.js`, and — if it should exist in FP form — register it in the right `fp/_mapping.js` tables. `fp/_mapping.js` is the real registry: arity bucket, rearg order, iteratee cap, spread config, mutation class, alias and remap are all declarative. `_baseConvert`'s `wrappers` object is the escape hatch for methods whose conversion can't be expressed in tables. At runtime, `_.mixin` and `_.runInContext` are the library's public extension APIs, and `templateSettings` is the configuration hook for `_.template`.
- The method registry is the literal assignment block near the end of `runInContext` — every public method appears as `lodash.<name> = <name>`, and omitting a line there makes an implemented function unreachable.
- `mapping.aryMethod[1|2|3|4]` is the primary FP registration point: `_baseConvert` iterates exactly these buckets to decide which methods get wrapped, and `lib/fp/build-modules.js` unions them into `aryMethods` to decide `module.jst` vs `thru.jst`.
- `_baseConvert`'s `wrappers` object is a named override table — `castArray`, `iteratee`, `mixin`, `nthArg`, `rearg`, `runInContext` each get bespoke conversion logic that bypasses the table-driven pipeline.
- `mapping.remap` lets an FP-only method name map onto a different real lodash method, and `build-modules.js` reads it both to emit extra module paths and, via `_.get(mapping.remap, name, name)`, to write the correct `require` inside the generated module.
- `mapping.aliasToReal` drives three things at once: alias resolution inside `wrap()`, the `alias.jst` re-export module, and the generated FP-Guide's alias listing.
- Opting a method out of FP transforms is declarative: add its name to `mapping.skipFixed` (no arity cap) or `mapping.skipRearg` (no argument reordering), both read inside `castFixed`/`castRearg`.
- The `lib/fp/template/modules/*.jst` set is the emission plugin surface — `getTemplate()` dispatches to `alias`, `category`, `thru` or `module` based on `isAlias`/`isCategory`/`isThru`, so a new module shape means a new `.jst` plus a branch there.
- `file.globTemplate` auto-discovers templates by glob and keys them by basename, so dropping a new `.jst` into `lib/fp/template/modules/` makes it available as `template.<basename>` without registering it anywhere.
- `_.mixin(object, source, options)` is the public plugin API: it walks `baseFunctions(source)`, assigns each onto the target, and when the target is a function also installs a chain-aware prototype method honoring `options.chain`.
- `_.runInContext(context)` is the sandboxing extension point — the `contextProps` array enumerates the 30 substitutable globals, documented with the example of swapping `setTimeout` for `setImmediate`.
- `lodash.templateSettings` is the documented configuration object for `_.template`'s `escape`/`evaluate`/`interpolate` delimiters, `imports` and `variable`, read at the top of `template()`.
- The doc pipeline is configured by the `config` object in `lib/main/build-doc.js`, keyed `base`/`github`/`site` and merged with `_.defaults`; adding a third output style means adding a key there and a matching npm script.
- The Playwright project list in `playwright.config.js` is the browser-matrix registry — adding a browser or device is one entry in `projects`, and adding a page to test is one `test()` block in `test/playwright-runner.spec.js`.
- `lib/fp/build-modules.js` hardcodes an 11-entry `categories` list and an `ignored` glob list; a new lodash category or a new private-file naming convention requires editing both arrays.
- `test-ui.js`'s `ui.buildPath` switch is the harness registry for testable builds — the four cases (`lodash`, `lodash-dev`, `lodash-core`, `lodash-core-dev`) must be kept in sync with the `<option>` values written into the toolbar.