ZXing JS in maintenance mode, with two lockfiles and an import missing from its own example

The page opens by declaring maintenance mode and advertising a paid alternative

The first thing the page does is qualify itself, and it does so twice. A warning block states that the project is in maintenance mode, that changes are driven by contributed patches, that only bug fixes and minor enhancements will be considered, and that there is otherwise no active development or roadmap, describing the project as DIY. A second note says the maintainers do not have the time to maintain it anymore and are open to new maintainers taking the lead. Above both, the page opens by asking whether you want a maintained barcode scanning library with commercial support and pointing at a commercial product instead. That is an unusual thing for a project README to lead with, and it tells you the state of the project more plainly than the commit history does. The last push to the master branch is dated 2026-10-02.

Twenty months passed between v0.21.3 and v0.22.0

The release tags describe the same rhythm the warning describes. v0.21.3 was published 2024-08-21, v0.22.0 on 2026-04-27 and v0.23.0 on 2026-04-29, so the project went twenty months between tags and then shipped two in three days. The manifest is at 0.23.0, matching the newest tag, which tells you the working tree and the published package are in step. The larger picture is that this is a port rather than the original: the page describes ZXing as an open-source multi-format 1D and 2D barcode image processing library implemented in Java, with ports to other languages, and the repository description calls this one the TypeScript port usable in the JavaScript ecosystem. Special thanks are given to the person who created the project and made the initial QR code port available, which dates the origin to the first symbology rather than the full set.

Three 2D formats are marked as needing work in the support table

The formats table is a three-column list, and three entries carry a warning in the cell itself. Under 1D product you get UPC-A, UPC-E, EAN-8 and EAN-13; under 1D industrial, Code 39, Code 93, Code 128, Codabar and ITF; under 2D, QR Code, Data Matrix, Aztec and PDF 417, followed by MaxiCode marked as needing testing, RSS-14 with no comment, RSS-Expanded marked as not production ready and Micro-QR marked as needing testing. So a quarter of the 2D column is qualified by the project itself, and the distinction between RSS-14 and RSS-Expanded is one character in the name with opposite readiness. The page points at the repository's project board and milestones for what is done and what is planned, which in a maintenance-mode project is where a reader should look before choosing a format.

The usage snippet references a class it never imports

The usage example is short and readable, and it is missing an import:

// use with commonJS
const { MultiFormatReader, BarcodeFormat } = require('@zxing/library');
// or with ES6 modules
import { MultiFormatReader, BarcodeFormat } from '@zxing/library';

const hints = new Map();
const formats = [BarcodeFormat.QR_CODE, BarcodeFormat.DATA_MATRIX/*, ...*/];

hints.set(DecodeHintType.POSSIBLE_FORMATS, formats);

const reader = new MultiFormatReader();

const luminanceSource = new RGBLuminanceSource(imgByteArray, imgWidth, imgHeight);
const binaryBitmap = new BinaryBitmap(new HybridBinarizer(luminanceSource));

reader.decode(binaryBitmap, hints);

It opens by destructuring MultiFormatReader and BarcodeFormat from the package, whether through require or through an ES module import, builds a hints map, sets a format array containing BarcodeFormat.QR_CODE and BarcodeFormat.DATA_MATRIX, and then calls hints.set with DecodeHintType.POSSIBLE_FORMATS. DecodeHintType is never imported in the snippet. Copying it as printed leaves that name undefined. The rest of the pipeline is the interesting part: an RGBLuminanceSource built from a byte array with width and height, wrapped in a BinaryBitmap over a HybridBinarizer, and passed to reader.decode along with the hints. So the decoding path takes raw pixels rather than an image element, which is why the binarizer is a parameter and not an internal detail.

BigInt is the one browser dependency with no polyfill offered

The browser support section lists three requirements in order of how hard they are to satisfy. The browser layer uses the MediaDevices web API, which older browsers do not support, and the page suggests external polyfills such as the WebRTC adapter. The library also uses typed arrays, Int32Array and Uint8ClampedArray among them, which are unavailable in older browsers such as the Android 4 default browser, and core-js is offered as the fix. The third is different in kind: the PDF 417 decoder is a recent addition that uses the BigInt type, which is not supported by all browsers, and the page says plainly that there is no way to polyfill that, that ponyfill libraries are too big, and that even though PDF 417 decoding relies on BigInt the rest of the library works in browsers without it. It repeats the point once more: no polyfill exists for BigInt in the way it is coded here.

The iOS camera restriction predates the note that lifted it

The limitations section explains that on iOS devices with iOS below 14.3, camera access works only in native Safari and not in other browsers or in apps using UIWebView or WKWebView. The page attributes this to Apple's limited WebRTC support rather than to the library, and then hedges about the future with a sentence saying the behaviour might change in iOS 11.3, annotated with a question mark about the date and the note that it was not tested. Underneath sits the resolution: a line stating that iOS 14.3, released in December 2020, now supports WebRTC in third-party browsers as well. So the restriction described above it has not existed since December 2020, and the page has kept both halves. A reader arriving today gets a caveat that no longer applies, followed by the sentence that says so.

Five entry points, five tsconfigs, and an esnext field pointing at es2015

The manifest publishes the library five ways and each one has its own TypeScript project. main points at ./cjs/index.js, module at ./esm/index.js, typings at ./esm/index.d.ts, esnext at ./es2015/index.js and unpkg at ./umd/index.min.js. The build script chains them in order: clean, then es2015, esm, esnext, cjs, umd, umd:min and a copy step, each TypeScript flavour compiled with its own config file and the UMD bundle produced by rollup rather than tsc. Two details fall out of that list. The esnext field resolves to the es2015 build, so a bundler reading that field gets the previous-target output. And the minified UMD step pipes terser output through gzip into a .gz beside it, which means the published bundle ships as a compressed artifact inside the package as well as on a CDN.

Two lockfiles, two formatter configs, and a Node floor with no ceiling

The root of the repository carries both package-lock.json and yarn.lock, and the installation section offers both npm i @zxing/library --save and yarn add @zxing/library, so either tool is a supported path with a lockfile committed for it. The formatting configuration is similarly doubled: a .prettierrc and a .unibeautify.json sit side by side, alongside eslint.config.mjs, jest.config.js and rollup.config.mjs, which means three separate tool configurations for one package. The Node requirement is a single floor, engines node >= 24.0.0, with no upper bound. The remaining root files are the conventional ones for a documented project: LICENSE, CONTRIBUTING.md, a HELPER_REGEX.md, a docs directory, a _config.yml for the published site, and an editorconfig.

Editorial conclusion

This library is a sound choice for QR, Data Matrix, Aztec and the common 1D symbologies in a browser or an Angular app, and it is not a choice for anything needing a roadmap or a responsive maintainer, because the page says so in those terms. Three things to verify before you adopt it. The formats you actually need, since MaxiCode and Micro-QR are marked as needing testing and RSS-Expanded as not production ready, which is the project's own assessment rather than a third-party one. The platform you deploy to, because camera capture before iOS 14.3 works only in Safari, older browsers need MediaDevices and TypedArray polyfills, and PDF 417 decoding needs BigInt with no polyfill available. And the state of your lockfile, since the repository carries both package-lock.json and yarn.lock and both are advertised as install routes, so pick one and keep the project consistent with the choice.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. zxing-js/library on GitHub