fbjs

fbjs is Meta’s (Facebook’s) internal collection of small, dependency-light JavaScript utility functions, originally created to let projects like React and Relay share common helpers such as object iteration, string-case conversion, and DOM manipulation without pulling in several separate npm packages. It bundles modules for functional-programming primitives (mapObject, forEachObject, filterObject), string transformation (camelize, hyphenate, camelizeStyleName), browser and DOM helpers (ExecutionEnvironment, CSSCore, DOMMouseMoveTracker, normalizeWheel), a cross-fetch-based fetch wrapper, and assorted polyfills (Promise, setImmediate, requestAnimationFrame shims).

Because it was designed around Facebook’s internal @providesModule build system rather than as a public-facing library, its API surface can shift between releases and the maintainers are explicit that outside feature requests aren’t a priority. Today it’s most often encountered as a transitive dependency pulled in by older React-ecosystem packages rather than something developers add directly to a new project.

What You Get

• Functional helpers - mapObject, forEachObject, filterObject, groupArray, and distinctArray for iterating and transforming plain objects and arrays without a full utility-belt library.
• String and style-name utilities - camelize, hyphenate, camelizeStyleName, and hyphenateStyleName for converting between JS identifier casing and CSS property naming.
• DOM and browser helpers - ExecutionEnvironment, CSSCore, DOMMouseMoveTracker, and normalizeWheel for runtime feature detection and cross-browser event handling.
• Polyfills and forks - Promise, setImmediate, requestAnimationFrame, and a cross-fetch-based fetch shim for older runtime targets.
• Async and collection primitives - PromiseMap, Deferred, and enumerate for common async and keyed-collection patterns used across Facebook’s JS codebases.

Common Use Cases

• Legacy React-ecosystem dependency - projects built on older React, Relay, or Draft.js tooling pull in fbjs transitively for the shared helper functions those libraries depend on.
• DOM feature detection in cross-browser code - teams maintaining older browser-compatible UI code use ExecutionEnvironment and CSSCore instead of hand-rolling environment checks.
• Object/array transformation without a full utility library - codebases wanting a smaller footprint use fbjs’s functional helpers (mapObject, filterObject) instead of lodash.
• Style-name conversion in CSS-in-JS tooling - libraries that generate inline styles use camelizeStyleName/hyphenateStyleName to translate between JS and CSS property names.

Under The Hood

Architecture fbjs is a flat collection of independent, single-purpose modules under packages/fbjs/src/{core,dom,functional,fetch,crypto,intl,unicode,…}, historically built around Facebook’s internal @providesModule system and now published as plain CommonJS requires. The repository itself is a small monorepo: sibling packages (babel-preset-fbjs, fbjs-scripts, fbjs-css-vars, eslint-config-fbjs, signedsource) exist purely to build, lint, and test the fbjs package rather than to share runtime code with it. Because each utility module is self-contained with no shared internal dependency graph binding them together, removing or changing one abstraction (say, ExecutionEnvironment) only affects the handful of files that explicitly require it — there is no central orchestration layer, which keeps the codebase easy to reason about but also means it functions more as a flat toolbox than a designed system.

Tech Stack The project is plain JavaScript (no TypeScript, with only optional Flow annotations checked separately via yarn flow), built with gulp and gulp-babel through the shared babel-preset-fbjs preset, and tested with Jest via Facebook’s own fbjs-scripts jest environment and preprocessor packages rather than a stock Jest config. Runtime dependencies are deliberately minimal — cross-fetch, ua-parser-js, object-assign, promise, setimmediate, and loose-envify — and the declared devEngines floor (Node >=4.x, npm >=2.x) reflects the library’s age and its original internal-tooling origins.

Code Quality Test coverage is extensive in breadth but shallow in depth: dozens of __tests__ directories sit alongside their corresponding modules, each with a handful of focused describe/it unit tests using Jest’s manual-mock system (jest.unmock). There is no enforced static typing at build or test time — Flow checking exists as a separate opt-in script — and error handling in the small utility functions themselves is minimal and implicit, consistent with a low-level helper library rather than an application. ESLint configuration is present via the sibling eslint-config-fbjs packages, but nothing in this snapshot shows it wired into a CI gate.

API Design The developer experience trades ergonomics for narrowness: each module does exactly one thing and is required by its own file path (e.g. fbjs/lib/mapObject), so there’s essentially no discovery surface or unified entry point — the root index.js even throws if required directly, insisting on full per-module paths instead. Documentation is limited to the top-level README’s explanation of the @providesModule rewrite process, with no per-function API docs; the maintainers are explicit that the library is shaped by Facebook’s internal needs rather than external developer convenience, so adopting it well requires reading source files directly.