Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Backport #308 to apply to 0.6

Open
#370 10 comments 24 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
javascript

Research direction

Start by reviewing the performance changes in #308 and the linked 0.6.1-to-patch-0.6.1 comparison on the fork. Apply the backport to the 0.6 line, then verify source-map generation performance against the reported production-build regression. Done means the improvement is available in a 0.6.2 release.

Written by the indexing model from the issue text.

Description

needs-triage wasm

Many libraries won't be upgrading to source-map 0.7 until Node 6 is out of the LTS schedule (example: https://github.com/webpack/webpack-sources/issues/34#issuecomment-423752839). That is still 5-6 months away.

When I upgraded my project from Node 8 to Node 10, I was surprised to see that the performance of source-map generation was significantly diminished. A webpack production build went from taking 4 minutes to 20 minutes, and all that extra time can be attributed to source-map generation. Thanks to this issue thread -- https://github.com/webpack-contrib/uglifyjs-webpack-plugin/issues/272#issuecomment-427206345 -- it looks like #308 fixes the issue. I'm hoping it's possible to take @marcins 's suggestion, backport this significant performance improvement, and release it as 0.6.2.

I've made the necessary changes to backport the performance improvements in #308 on my fork: https://github.com/mozilla/source-map/compare/0.6.1...benthemonkey:patch-0.6.1

With these changes I found that my production build time goes back to taking 4 minutes.

Dominant language
JavaScript
Stars
3.7k
Forks
370
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mozilla/source-map

All issues in mozilla/source-map

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.