Repository navigation
generator-only package #446
Description
I just made a relatively-aggressive fork here that removes the consumer code as well as the reliance on what-wg-url. I have kept all of the license, contributors, etc. in place. All of my changes are deletions and minor fixups to make the tests work.
The goal is to have something small to bundle with peggy's upcoming support for source-map generation.
I apologize for not discussing it here first. I would be happy to either keep the new repo in sync with whatever changes are made here, or defork and hand over the keys to npm if this project is interested in publishing something that uses the name.
Please let me know if it concerns you or you'd like me to take some other action.
Activity
cspotcode commentedon Aug 30, 2021
I also needed to make a fork to add a sync WASM API and publish a consumer-only package. Would you like to combine our efforts? We could move the project to a shared, neutral location if you would like.
http://npm.im/@cspotcode/source-map
http://npm.im/@cspotcode/source-map-consumer
https://github.com/cspotcode/source-map
hildjj commentedon Sep 23, 2022
Sorry, I missed your note when it came by the first time, @cspotcode. I'm happy to collaborate. I'll send a note to the email in your package to discuss.
cspotcode commentedon Sep 23, 2022
No worries, that's how it goes with open-source. It was actually a year and a month ago, haha.
I got your email but I prefer to keep all my OSS communications in the open; avoids the need to repeat things. Mind if we keep discussion here or in a new issue? Either works for me.
hildjj commentedon Sep 24, 2022
Here is fine. I think the first step is to write a little doc that describes the different sub-libraries, how they would fit together, how we would transition to that system, and what changes would need to be made to existing users of the system.
cspotcode commentedon Sep 24, 2022
In the year since my post above, I actually ended up removing my source-map dependency in favor of another library. It seemed like other components of the ecosystem were doing the same, I wanted to reduce maintenance burden by going for something that seemed to be independently maintained. And for my purposes, I only needed a consumer, not a generator.
https://github.com/cspotcode/node-source-map-support/blame/69baeb8ccbf9f2a342c8575f21ac81f5d711eb81/package.json#L21-L23
So maybe another thing to figure out in that doc: is it worth maintaining this library? Since the ownership transfer from mozilla is still uncertain.
I'm generally in favor of less churn, and maintaining long-standing tools. But at the same time, I don't want to create unnecessary work.
hildjj commentedon Sep 24, 2022
I haven't looked deeply into node's native source-map consumer yet. I wonder if it should be mentiond as well? https://nodejs.org/api/module.html#class-modulesourcemap
cspotcode commentedon Sep 24, 2022
I think the native one has bad performance compared to third-party options. A while back there was a node stack trace bug that generated a bunch of conversation, and as part of that, I linked to a benchmark: nodejs/node#42417 (comment)
hildjj commentedon Sep 24, 2022
Is the perf still that bad after nodejs/node#41541 landed?
cspotcode commentedon Sep 24, 2022
I'm not sure, the benchmarks could be re-run against a new node version.
cspotcode commentedon Sep 24, 2022
New results don't look better: https://github.com/cspotcode/source-map-performance-demo#example-output
Maybe you can double-check my results. Running the benchmark is
git clone;yarnornpm installand thenyarn startto build and run the benchmark.hildjj commentedon Sep 25, 2022
I see similar results here.
Results for 10000 stack traces.
hildjj commentedon Sep 26, 2022
I started a doc here: https://github.com/hildjj/source-map-architecture
Please open issues there and send PRs.