Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

allow wasm to be bundled

Đang mở
  • Có gì không ổn?
#527 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
javascript, node.js, wasm
Lĩnh vực
build-system, tooling

Hướng nghiên cứu

Bắt đầu với read-wasm.js, read-wasm-browser.js, package.json và điểm vào SourceMapConsumer.initialize để hiểu fallback Node hiện tại và việc mapping trên trình duyệt. Xác minh rằng một Node consumer được đóng gói có thể cung cấp WASM thông qua initialize mà không cần thay đổi module, đồng thời fallback mappings.wasm hiện có vẫn hoạt động khi không có input nào được cung cấp.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Support bundlers (esbuild, webpack) without requiring internal module swaps for WASM loading

Problem

When bundling source-map with esbuild (platform: node), the WASM loading breaks in production because:

  1. read-wasm.js uses path.join(__dirname, "mappings.wasm") — but after bundling, __dirname points to the output directory, not node_modules/source-map/lib/
  2. initialize() is a no-op in the Node version (read-wasm.js), so there's no way to provide the WASM from the consumer side without swapping to read-wasm-browser.js via a bundler resolve plugin
  3. The "browser" field in package.json maps read-wasm.js → read-wasm-browser.js, but esbuild with platform: node (correctly) ignores browser fields

This forces users to either:

  • Copy mappings.wasm to their output directory with the exact filename (fragile, undocumented contract)
  • Use a resolve plugin to swap read-wasm.js → read-wasm-browser.js and manually call initialize() (depends on internal file paths)

Proposal

Make initialize() work regardless of platform — if the user provides WASM via initialize(), use it; otherwise fall back to the fs.readFile(__dirname) approach. This is essentially making the Node read-wasm.js behave like:

let initialized = null;

module.exports = function readWasm() {
  if (initialized) return Promise.resolve(initialized);
  // existing fs.readFile fallback
  return new Promise((resolve, reject) => {
    const wasmPath = path.join(__dirname, "mappings.wasm");
    fs.readFile(wasmPath, null, (error, data) => {
      if (error) reject(error);
      else resolve(data.buffer);
    });
  });
};

module.exports.initialize = function (input) {
  initialized = input;
};

This way bundler users can call SourceMapConsumer.initialize({"lib/mappings.wasm": wasmBuffer}) on Node without needing to swap modules.

Alternatives considered

  • Exporting mappings.wasm via package.json "exports" so bundlers can resolve it cleanly
  • Shipping a pre-built JS fallback (like source-map-js does — no WASM at all)

Environment

  • source-map 0.7.6
  • esbuild 0.28.x, platform: node, format: esm
  • Node.js 24.x
  • Deploying to Docker (only dist/ is copied — no node_modules)
Ngôn ngữ chính
JavaScript
Star
3.7k
Fork
374
Merge trung bình
4 ngày 18 giờ
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của mozilla/source-map

Tất cả issue của mozilla/source-map

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.