Package detail

zxing-wasm

Sec-ant294.1kMIT2.1.2

ZXing-C++ WebAssembly as an ES/CJS module with types

qrcode, barcode, wasm, zxing, zxing-cpp, esmodule, webassembly

readme

[!NOTE]

For the v1 release, please visit the channel/v1 branch.

zxing-wasm

ZXing-C++ WebAssembly as an ES/CJS module with types. Read or write barcodes in various JS runtimes: Web, Node.js, Bun, and Deno.

Barcode Format	Linear Barcode	Matrix Barcode	Reading Support
`Aztec`	\| ✅	✅	✅
`Codabar`	✅	\| ✅	✅
`Code39`	✅	\| ✅	✅
`Code93`	✅	\| ✅	✅
`Code128`	✅	\| ✅	✅
`DataBar`	✅	\| ✅	✅
`DataBarLimited`	✅	\| ✅	✅
`DataBarExpanded`	✅	\| ✅	✅
`DataMatrix`	\| ✅	✅	✅
`DXFilmEdge`	✅	\| ✅	✅
`EAN-8`	✅	\| ✅	✅
`EAN-13`	✅	\| ✅	✅
`ITF`	✅	\| ✅	✅
`MaxiCode`	\| ✅	✅[^1]	✅
`PDF417`	\| ✅	✅	✅
`QRCode`	\| ✅	✅	✅
`MicroQRCode`	\| ✅	✅	✅
`rMQRCode`	\| ✅	✅	✅
`UPC-A`	✅	\| ✅	✅
`UPC-E`	✅	\| ✅	✅

[^1]: Reading support for MaxiCode requires a pure monochrome image that contains an unrotated and unskewed symbol, along with a sufficient white border surrounding it.

Visit this online demo to quickly explore its basic reading functions. It works best on the latest Chromium browsers.

Build

git clone --recurse-submodules https://github.com/Sec-ant/zxing-wasm
cd zxing-wasm

# Install pnpm before executing the next command:
# https://pnpm.io/installation
pnpm i --frozen-lockfile

# Install CMake before executing the next command:
# https://cmake.org/download/
# Install Emscripten before executing the next command:
# https://emscripten.org/docs/getting_started/downloads.html
pnpm build:wasm

pnpm build

Install

npm i zxing-wasm

Documentation

https://zxing-wasm.deno.dev/

Demo

Demo page: https://zxing-wasm-demo.deno.dev/

Demo source: https://github.com/Sec-ant/zxing-wasm-demo

Usage

This package exports three subpaths: full, reader, and writer.

`zxing-wasm` or `zxing-wasm/full`

These two subpaths provide functions to read and write barcodes. The wasm binary size is ~1.31 MB.

import { readBarcodes, writeBarcode } from "zxing-wasm";

import { readBarcodes, writeBarcode } from "zxing-wasm/full";

`zxing-wasm/reader`

This subpath only provides a function to read barcodes. The wasm binary size is ~911 KB.

import { readBarcodes } from "zxing-wasm/reader";

`zxing-wasm/writer`

This subpath only provides a function to write barcodes. The wasm binary size is ~600 KB.

import { writeBarcode } from "zxing-wasm/writer";

IIFE Scripts

Apart from ES and CJS modules, this package also ships IIFE scripts. The registered global variable is named ZXingWASM, where you can access all the exported functions and variables under it.

[!NOTE] Replace the <version> with the desired version number.

<!-- full -->
<script src="https://cdn.jsdelivr.net/npm/zxing-wasm@<version>/dist/iife/full/index.js"></script>

<!-- reader -->
<script src="https://cdn.jsdelivr.net/npm/zxing-wasm@<version>/dist/iife/reader/index.js"></script>

<!-- writer -->
<script src="https://cdn.jsdelivr.net/npm/zxing-wasm@<version>/dist/iife/writer/index.js"></script>

`readBarcodes`

readBarcodes accepts an image Blob, image File, ArrayBuffer, Uint8Array, or an ImageData as its first argument, and various options are supported in ReaderOptions as an optional second argument.

The return result of this function is a Promise of an array of ReadResults.

e.g.

import { readBarcodes, type ReaderOptions } from "zxing-wasm/reader";

const readerOptions: ReaderOptions = {
  tryHarder: true,
  formats: ["QRCode"],
  maxNumberOfSymbols: 1,
};

/**
 * Read from image file/blob
 */
const imageFile = await fetch(
  "https://api.qrserver.com/v1/create-qr-code/?size=150x150&data=Hello%20world!",
).then((resp) => resp.blob());

const imageFileReadResults = await readBarcodes(imageFile, readerOptions);

console.log(imageFileReadResults[0].text); // Hello world!

/**
 * Read from image data
 */
const imageData = await createImageBitmap(imageFile).then((imageBitmap) => {
  const { width, height } = imageBitmap;
  const context = new OffscreenCanvas(width, height).getContext(
    "2d",
  ) as OffscreenCanvasRenderingContext2D;
  context.drawImage(imageBitmap, 0, 0, width, height);
  return context.getImageData(0, 0, width, height);
});

const imageDataReadResults = await readBarcodes(imageData, readerOptions);

console.log(imageDataReadResults[0].text); // Hello world!

`writeBarcode`

The first argument of writeBarcode is a text string or an Uint8Array of bytes to be encoded, and the optional second argument WriterOptions accepts several writer options.

The return result of this function is a Promise of a WriteResult.

e.g.

import { writeBarcode, type WriterOptions } from "zxing-wasm/writer";

const writerOptions: WriterOptions = {
  format: "QRCode",
  scale: 3,
};

const writeOutput = await writeBarcode("Hello world!", writerOptions);

console.log(writeOutput.svg); // An SVG string.
console.log(writeOutput.utf8); // A multi-line string made up of " ", "▀", "▄", "█" characters.
console.log(writeOutput.image); // A PNG image blob.

Configuring `.wasm` Serving

Serving via Web or CDN

When using this package, a .wasm binary file needs to be served somewhere, so the runtime can fetch, compile and instantiate the WASM module. To provide a smooth development experience, the serve path is automatically assigned a jsDelivr CDN URL upon build.

If you want to change the serve path to your own server or other CDNs, please use prepareZXingModule and pass an overrides object with a custom defined locateFile function before reading or writing barcodes. locateFile is one of the Emscripten Module attribute hooks that can affect the code execution of the Module object during its lifecycle.

e.g.

import { prepareZXingModule, writeBarcode } from "zxing-wasm";

// Override the locateFile function
prepareZXingModule({
  overrides: {
    locateFile: (path, prefix) => {
      if (path.endsWith(".wasm")) {
        return `https://unpkg.com/zxing-wasm@2/dist/full/${path}`;
      }
      return prefix + path;
    },
  },
});

// Call read or write functions afterward
const writeOutput = await writeBarcode("Hello world!");

[!NOTE]

The default jsDelivr CDN serve path is also achieved by overriding the custom locateFile function:
const DEFAULT_MODULE_OVERRIDES: ZXingModuleOverrides = {
  locateFile: (path, prefix) => {
    const match = path.match(/_(.+?)\.wasm$/);
    if (match) {
      return `https://fastly.jsdelivr.net/npm/zxing-wasm@${ZXING_WASM_VERSION}/dist/${match[1]}/${path}`;
    }
    return prefix + path;
  },
};
However, overrides is atomic. If you override other Module attributes, you probably should also provide a locateFile function to ensure the .wasm file is fetched correctly.

Integrating in Non-Web Runtimes

If you want to use this library in non-web runtimes (such as Node.js, Bun, Deno, etc.) without setting up a server, there are several possible approaches. Because API support can differ between runtime environments and versions, you may need to adapt these examples or choose alternative methods depending on your specific runtime’s capabilities. Below are some example configurations for Node.js.

Use the Module.instantiateWasm API

import { readFileSync } from "node:fs";
import { prepareZXingModule } from "zxing-wasm/reader";

const wasmFileBuffer = readFileSync("/path/to/the/zxing_reader.wasm");

prepareZXingModule({
  overrides: {
    instantiateWasm(imports, successCallback) {
      WebAssembly.instantiate(wasmFileBuffer, imports).then(({ instance }) =>
        successCallback(instance),
      );
      return {};
    },
  },
});

Use the Module.wasmBinary API

import { readFileSync } from "node:fs";
import { prepareZXingModule } from "zxing-wasm/reader";

prepareZXingModule({
  overrides: {
    wasmBinary: readFileSync("/path/to/the/zxing_reader.wasm")
      .buffer as ArrayBuffer,
  },
});

Use the Module.locateFile API with an Object URL

import { readFileSync } from "node:fs";
import { prepareZXingModule } from "zxing-wasm/reader";

// Create an Object URL for the .wasm file.
const wasmFileUrl = URL.createObjectURL(
  new Blob([readFileSync("/path/to/the/zxing_reader.wasm")], {
    type: "application/wasm",
  }),
);

prepareZXingModule({
  overrides: {
    locateFile: (path, prefix) => {
      if (path.endsWith(".wasm")) {
        return wasmFileUrl;
      }
      return prefix + path;
    },
    // Call `URL.revokeObjectURL(wasmFileUrl)` after the ZXing module
    // is fully instantiated to free up memory.
    postRun: [
      () => {
        URL.revokeObjectURL(wasmFileUrl);
      },
    ],
  },
});

Use the Module.locateFile API with a Base64-encoded Data URL (Not recommended)

import { readFileSync } from "node:fs";
import { prepareZXingModule } from "zxing-wasm/reader";

const wasmBase64 = readFileSync("/path/to/the/zxing_reader.wasm").toString(
  "base64",
);
const wasmUrl = `data:application/wasm;base64,${wasmBase64}`;

prepareZXingModule({
  overrides: {
    locateFile: (path, prefix) => {
      if (path.endsWith(".wasm")) {
        return wasmUrl;
      }
      return prefix + path;
    },
  },
});

[!NOTE] To use this library in a WeChat mini program , there are several things to keep in mind:
Only the zxing-wasm import path is supported; zxing-wasm/reader or zxing-wasm/writer is not supported.

Before using the library, you need to copy/move the node_modules/zxing-wasm/dist/full/zxing_full.wasm file into your project directory.
You must use prepareZXingModule to configure how the .wasm file will be fetched, loaded, and compiled before calling readBarcodes or writeBarcode. This is mandatory, and you can do so with the following code:
prepareZXingModule({
  overrides: {
    instantiateWasm(imports, successCallback) {
      WXWebAssembly.instantiate("path/to/zxing_full.wasm", imports).then(
        ({ instance }) => successCallback(instance),
      );
      return {};
    },
  },
});
Note that WeChat mini programs use WXWebAssembly instead of the standard WebAssembly, and the first argument in WXWebAssembly.instantiate should point to the location where the zxing_full.wasm file was moved earlier.
This library uses a bare minimum Blob polyfill in the mini program environment so that no errors will be thrown if you call writeBarcode. However, it's recommended to use a full-fledged Blob polyfill for not breaking other parts of your program.

[!IMPORTANT]

Each version of this library has a unique corresponding .wasm file. If you choose to serve it yourself, please ensure that the .wasm file matches the version of the zxing-wasm library you are using. Otherwise, you may encounter unexpected errors.

For convenience, this library provides an exported ZXING_WASM_VERSION variable to indicate the resolved version of the zxing-wasm you are using:

import { ZXING_WASM_VERSION } from "zxing-wasm";

The commit hash of the zxing-cpp submodule is exported as ZXING_CPP_COMMIT:

import { ZXING_CPP_COMMIT } from "zxing-wasm";

The SHA-256 hash of the .wasm file (in hex format) is also exported as ZXING_WASM_SHA256, in case you want to make sure you are serving the exactly same file:

import { ZXING_WASM_SHA256 } from "zxing-wasm";

To acquire the .wasm files for customized serving, in addition to finding them by searching in your node_modules folder, they can also be downloaded from CDNs like jsDelivr:

zxing_full.wasm:

https://cdn.jsdelivr.net/npm/zxing-wasm@<version>/dist/full/zxing_full.wasm

zxing_reader.wasm:

https://cdn.jsdelivr.net/npm/zxing-wasm@<version>/dist/reader/zxing_reader.wasm

zxing_writer.wasm:

https://cdn.jsdelivr.net/npm/zxing-wasm@<version>/dist/writer/zxing_writer.wasm

Controlling `.wasm` Instantiation Timing and Caching

By default, the .wasm binary will not be fetched and instantiated until a readBarcodes or writeBarcode function is called. This behavior avoids unnecessary network requests and instantiation overhead if you decide to override the default .wasm serving path or other settings before using the library. Calling prepareZXingModule with overrides alone does not change this default behavior:

prepareZXingModule({
  overrides: {
    /* ... your desired overrides ... */
  },
}); // <-- returns void

However, if you want to explicitly trigger the download and instantiation of the .wasm binary, you can set the fireImmediately option to true. Doing so also causes prepareZXingModule to return a Promise that resolves to the underlying Emscripten module. This allows you to await the instantiation process:

prepareZXingModule({
  overrides: {
    /* ... your desired overrides ... */
  },
  fireImmediately: true,
}); // <-- returns a promise

Because different overrides settings can influence how this library locates and instantiates the .wasm binary, the library performs an equality check on overrides to determine if the .wasm binary should be re-fetched and re-instantiated. By default, it is determined by a shallow comparison of the overrides object. If you prefer a different method of comparison, you can supply a custom equalityFn:

prepareZXingModule({
  overrides: {
    /* ... your desired overrides ... */
  },
  fireImmediately: true,
  equalityFn: () => false, // <-- force re-fetch and re-instantiate
});

FAQ

Why are submodules required?

The core function of reading / writing barcodes of this library is provided by zxing-cpp. It is pinned to a specific commit ID as a submodule, and can be built as .wasm files. Additionally, the barcode generation ability is provided by zint, which is a submodule inside zxing-cpp, so it is necessary to clone the repository with --recurse-submodules to ensure that all required submodules are also cloned.
I forgot to clone the repository with --recurse-submodules, how should I install the submodules without deleting this repo and cloning it again?

In the root of the repo, run:
```
git submodule update --init --recursive
```
Are there any higher level libraries that can be used to simplify the usage of this library?
- barcode-detector: A Barcode Detection API polyfill / ponyfill that uses this library under the hood.
- vue-qrcode-reader: A set of Vue.js components for detecting QR codes and various other barcode formats right in the browser which uses barcode-detector under the hood.
- @yudiel/react-qr-scanner: A library to scan QR Codes in react which uses barcode-detector under the hood.
- svelte-qrcode-reader: A set of Svelte 5 components for detecting and decoding QR-codes which uses barcode-detector under the hood.
A React toolkit for scanning barcodes directly based on this library is planned, which aims to provide easy-to-use capabilities for interacting with web cameras.
One of the input types of readBarcodes is ImageData, which is a DOM type. How can I use it in Node.js or other runtimes?

The types are duck-typed, so you can use it in Node.js or other runtimes by providing a DOM-compatible ImageData object in the following shape, where the image data should be in RGBA format:
```
interface ImageData {
  data: Uint8ClampedArray;
  width: number;
  height: number;
}
```

Licenses

This project contains code from multiple sources, each with its own license:

zxing-cpp: Apache License 2.0
src/cpp/ZXingWasm.cpp: Apache License 2.0
zint: BSD 3-Clause License
zxing-wasm specific code: MIT License

changelog

zxing-wasm

2.1.2

Patch Changes

0be5882: Fix unexpected new URL(..., import.meta.url) expansion when bundling this package on the consumer side.
0be5882: Bump zxing-cpp to a1516b3 and bump other deps.

2.1.1

Patch Changes

5ff557f:
- Bump zxing-cpp to 559471a, also bump other deps;
- Bump emscripten to v4.0.7, adjust compiling/linking flags and patch scripts;
- Increase stack size to fix writer issues in #211 and #215 and add tests for them;

2.1.0

Minor Changes

98bcdb6: Support WeChat Mini Program.
98bcdb6: Accept ArrayBuffer and Uint8Array as input types in readBarcodes.

2.0.2

Patch Changes

3d12c62: Bump zxing-cpp to 37b8477 and other deps.

2.0.1

Patch Changes

6321b02: Add ZXING_CPP_COMMIT export.

2.0.0

This release introduces a major refactoring of the underlying Embind APIs and read / write functions. Key changes include a new set of default reader options, enhanced writer capabilities backed by zint, and updated APIs for reading and writing barcodes. These changes break backward compatibility, so we are upgrading to the next major version.

Breaking Changes

Consolidated Reader Function

readBarcodes(...) replaces both readBarcodesFromImageFile(...) and readBarcodesFromImageData(...). The new function can accept either a Blob or an ImageData as its input.

[!NOTE]

The v1 reader functions readBarcodesFromImageFile and readBarcodesFromImageData are still kept for a smooth migration experience, but marked as deprecated.

Updated Reader Options

A few reader options have changed their default values. This change is to align with the latest ZXing C++ library and provide a more consistent experience across different platforms:

tryCode39ExtendedMode is now true by default. It was previously false.
eanAddOnSymbol is now "Ignore" by default. It was previously "Read".
textMode is now "HRI" by default. It was previously "Plain".

Some deprecated options have been removed, see zxing-cpp#704 for more details:

validateCode39CheckSum is now removed. The Code39 symbol has a valid checksum if the third character of the symbologyIdentifier is an odd digit.
validateITFCheckSum is now removed. The ITF symbol has a valid checksum if the third character of the symbologyIdentifier is a '1'.
returnCodabarStartEnd is now removed. The detected results of Codabar symbols now always include the start and end characters.

`eccLevel` in Read Result Renamed to `ecLevel`

In ReadResult, the eccLevel field has been renamed to ecLevel. It now holds strings like "L", "M", "Q", or "H" or stringified numeric percentage values for error correction levels. An empty string indicates that the error correction level is not applicable.

[!NOTE]

The eccLevel field is still kept for a smooth migration experience, but marked as deprecated.

Renamed & Enhanced Writer Function

writeBarcode(...) replaces writeBarcodeToImageFile(...). This function is now powered by the new zint backend which supports all available formats that are currently supported by the reader. It accepts either a string text or an Uint8Array binary data as its input for barcode generation, and provides new output formats (e.g. SVG, UTF-8) in addition to an image file blob.

The WriterOptions object has also been updated completely.

[!NOTE]

The final shape of the writeBarcode function is still in review. The current implementation is subject to change.

`.wasm` Module Initialization / Caching Overhaul

prepareZXingModule(...) replaces both setZXingModuleOverrides(...) and getZXingModuleOverrides(...). The new function provides a more flexible way to initialize the ZXing module with custom options.

[!NOTE]

The v1 module initialization functions setZXingModuleOverrides and getZXingModuleOverrides are still kept for a smooth migration experience, but marked as deprecated.

purgeZXingModule now only clears the relevant module cache from where it is imported. It no longer resets the global module cache.

Redefined `BarcodeFormat`-Family Types

None is removed from the BarcodeFormat union type. New types like LinearBarcodeFormat, MatrixBarcodeFormat and LooseBarcodeFormat are introduced. See barcodeFormat.ts for more details.

New Features & Enhancements

More Barcode Formats Supported in Writer

The new writeBarcode function supports more barcode formats than the previous writeBarcodeToImageFile. All barcode formats supported by the reader are now supported by the writer.

New `tryDenoise` Option for Reading Barcodes

The new tryDenoise option in ReaderOptions allows you to enable or disable the denoising algorithm when reading barcodes. This is an experimental feature. By default, it is set to false.

Bug Fixes

Fix TS `moduleResolution: node` Subpath Exports Resolution

The subpath export types are now compatible with TypeScript's moduleResolution: node strategy by using the types-versions-wildcards strategy. This package now passes all the arethetypeswrong checks.

2.0.0-beta.4

Patch Changes

f8c33b2: Fix the zxing_writer.wasm size issue. See #190.

2.0.0-beta.3

Minor Changes

615a321: - Add DXFilmEdge writing support.
- Fix subpath exports TS compatibility with types-versions-wildcards strategy. Check this for more information.
- Add types to .wasm subpath exports.
- Add ImageData ambient type export.

2.0.0-beta.2

Patch Changes

b856d58: Add typesVersions field for moduleResolution: node

2.0.0-beta.1

Patch Changes

a10ffcc: Bump zxing-cpp to 0dfa36b to fix DataBarExpanded decoder error and ITF quiet zone detection heuristic

2.0.0-beta.0

Major Changes

1a77296: V2: Breaking Release - Next Major Version

This release introduces a major refactoring of the underlying Embind APIs and read / write functions. Key changes include transitioning away from Embind Enums toward numeric encoding and decoding, a new set of default reader options, enhanced writer capabilities backed by zint, and updated APIs for reading and writing barcodes. These changes break backward compatibility, so we are upgrading to the next major version.

Breaking Changes

Renamed & Consolidated Reader Function

readBarcodes(...) replaces both readBarcodesFromImageFile(...) and readBarcodesFromImageData(...). The new function unifies code paths for Blob and ImageData inputs.

[!NOTE]

The v1 reader functions readBarcodesFromImageFile and readBarcodesFromImageData are still kept for a smooth migration experience, but marked as deprecated.

Updated Reader Options

A few reader options have changed their default values. This change is to align with the latest ZXing C++ library and provide a more consistent experience across different platforms:
1. tryCode39ExtendedMode is now true by default. It was previously false.
2. eanAddOnSymbol is now "Ignore" by default. It was previously "Read".
3. textMode is now "HRI" by default. It was previously "Plain".
Some deprecated options have been removed, see zxing-cpp#704 for more details:
1. validateCode39CheckSum is now removed. The Code39 symbol has a valid checksum if the third character of the symbologyIdentifier is an odd digit.
2. validateITFCheckSum is now removed. The ITF symbol has a valid checksum if the third character of the symbologyIdentifier is a '1'.
3. returnCodabarStartEnd is now removed. The detected results of Codabar symbols now always include the start and end characters.
eccLevel in Read Result Renamed to ecLevel

In ReadResult, the eccLevel field has been renamed to ecLevel. It now holds strings like "L", "M", "Q", or "H" or stringified numeric values for error correction levels. An empty string indicates that the error correction level is not applicable.

[!NOTE]

The eccLevel field is still kept for a smooth migration experience, but marked as deprecated.

Renamed & Enhanced Writer Function

writeBarcode(...) replaces writeBarcodeToImageFile(...). The new function is powered by the new zint writer, which supports more barcode formats, supports both string and Uint8Array inputs for generating barcodes from text or binary data, and provides new output formats (e.g. SVG, UTF-8) in addition to the binary image file output.

The WriterOptions object has also been updated completely.

[!NOTE]

The final shape of the writeBarcode function is still under discussion. The current implementation is subject to change.

Module Initialization / Caching Overhaul

prepareZXingModule(...) replaces both setZXingModuleOverrides(...) and getZXingModuleOverrides(...). The new function provides a more flexible way to initialize the ZXing module with custom options.

[!NOTE]

The v1 module initialization functions setZXingModuleOverrides and getZXingModuleOverrides are still kept for a smooth migration experience, but marked as deprecated.

purgeZXingModule now only clears the relevant module cache from where it is imported. It no longer resets the global module cache.

New Features & Enhancements

More Barcode Formats Supported in Writer

The new writeBarcode function supports more barcode formats than the previous writeBarcodeToImageFile. All barcode formats supported by the reader except for DXFilmEdge are now supported by the writer.

New tryDenoise Option for Reading Barcodes

The new tryDenoise option in ReaderOptions allows you to enable or disable the denoising algorithm when reading barcodes. This is an experimental feature and by default, it is set to false.

1.3.4

Patch Changes

1a9a372: Bump zxing-cpp to 579650a to fix incorrect PDF417 position info.

1.3.3

Patch Changes

0709489: Bump zxing-cpp to cd9bba3 to fix an ITF detection regression.

1.3.2

Patch Changes

4b0ca08: Bump zxing-cpp to 308f820 and improve DataBar detection rate.

1.3.1

Patch Changes

999335b: Bump zxing-cpp to 8fb2f81 to support shorter ITF symbols.

1.3.0

Minor Changes

925e12f: Add reader support for DataBarLimited.

1.2.15

Patch Changes

fa87128: Fix webassembly exception handling. Increase success rate.
f1eef5c: Bump zxing-cpp to 81407a0 to fix reader options not being passed to the internal reader if isPure is set.

1.2.14

Patch Changes

aad8899: Patch emscripten to mitigate DOM Clobbering vulnerability.

1.2.13

Patch Changes

650c295: DOM Clobbering security patch.

1.2.12

Patch Changes

2228845: Bump zxing-cpp and switch to pnpm, renovate.

1.2.11

Patch Changes

d3c92ee:
- Always use .js as the chunk filename extension.
- Bump zxing-cpp to 986f785
- Bump dependencies

1.2.10

Patch Changes

0a43b27: Bump zxing-cpp to d0c1f34

1.2.9

Patch Changes

01e8878: Bump zxing-cpp to 441132c

1.2.8

Patch Changes

2fc9bec: Bump zxing-cpp to 4bbc1db

1.2.7

Patch Changes

308d165: Bump zxing-cpp to 9ca0684

1.2.6

Patch Changes

a2339d3: Bump zxing-cpp to b58682b.

1.2.5

Patch Changes

4358969: Fix WebAssembly instantiation issue in electron.

1.2.5-rc.0

Patch Changes

4358969: Fix WebAssembly instantiation issue in electron.

1.2.4

Patch Changes

f749591: Bump zxing-cpp to b3aff4a:
- Deprecate validateCode39CheckSum, validateITFCheckSum and returnCodabarStartEnd. Related commits from upstream: fc8f32d, b3fe574, d636c6d 68c97c7, 2f3c72c.
- Reduce WASM binaries size. Related commits from upstream: 6741403, 1fa0070, b3aff4a.
- Other fixes and improvements from upstream.

1.2.3

Patch Changes

de36dce: reset zxing-cpp to b152afd
- validateITFCheckSum, tryCode39ExtendedMode and validateCode39CheckSum are deprecated in later commits.

1.2.2

Patch Changes

02f0386: Bump zxing-cpp to b3fe574

Package detail

readme

zxing-wasm

Build

Install

Documentation

Demo

Usage

zxing-wasm or zxing-wasm/full

zxing-wasm/reader

zxing-wasm/writer

IIFE Scripts

readBarcodes

writeBarcode

Configuring .wasm Serving

Serving via Web or CDN

Integrating in Non-Web Runtimes

Controlling .wasm Instantiation Timing and Caching

FAQ

Licenses

changelog

zxing-wasm

2.1.2

Patch Changes

2.1.1

Patch Changes

2.1.0

Minor Changes

2.0.2

Patch Changes

2.0.1

Patch Changes

2.0.0

Breaking Changes

Consolidated Reader Function

Updated Reader Options

eccLevel in Read Result Renamed to ecLevel

Renamed & Enhanced Writer Function

.wasm Module Initialization / Caching Overhaul

Redefined BarcodeFormat-Family Types

New Features & Enhancements

More Barcode Formats Supported in Writer

New tryDenoise Option for Reading Barcodes

Bug Fixes

Fix TS moduleResolution: node Subpath Exports Resolution

2.0.0-beta.4

Patch Changes

2.0.0-beta.3

Minor Changes

2.0.0-beta.2

Patch Changes

2.0.0-beta.1

Patch Changes

2.0.0-beta.0

Major Changes

Breaking Changes

Renamed & Consolidated Reader Function

Updated Reader Options

eccLevel in Read Result Renamed to ecLevel

Renamed & Enhanced Writer Function

Module Initialization / Caching Overhaul

New Features & Enhancements

More Barcode Formats Supported in Writer

New tryDenoise Option for Reading Barcodes

1.3.4

Patch Changes

1.3.3

Patch Changes

1.3.2

Patch Changes

1.3.1

Patch Changes

1.3.0

Minor Changes

1.2.15

Patch Changes

1.2.14

Patch Changes

1.2.13

Patch Changes

`zxing-wasm` or `zxing-wasm/full`

`zxing-wasm/reader`

`zxing-wasm/writer`

`readBarcodes`

`writeBarcode`

Configuring `.wasm` Serving

Controlling `.wasm` Instantiation Timing and Caching

`eccLevel` in Read Result Renamed to `ecLevel`

`.wasm` Module Initialization / Caching Overhaul

Redefined `BarcodeFormat`-Family Types

New `tryDenoise` Option for Reading Barcodes

Fix TS `moduleResolution: node` Subpath Exports Resolution

`eccLevel` in Read Result Renamed to `ecLevel`

New `tryDenoise` Option for Reading Barcodes