generator-only package

[hildjj]

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.

[cspotcode]

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]

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]

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]

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]

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]

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]

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]

Is the perf still that bad after nodejs/node#41541 landed?

[cspotcode]

I'm not sure, the benchmarks could be re-run against a new node version.

[cspotcode]

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 ; yarn or npm install and then yarn start to build and run the benchmark.

[hildjj]

I see similar results here.

Results for 10000 stack traces.

node	compiler	options	stack_traces_correct	elapsed_ms
18.9.1	esbuild	--enable-source-maps	❌	220405
18.9.1	esbuild	-r @cspotcode/source-map-support/register	✅	264
18.9.1	esbuild	-r source-map-support/register	❌	342
18.9.1	esbuild			100
18.9.1	tsc	--enable-source-maps	❌	944
18.9.1	tsc	-r @cspotcode/source-map-support/register	✅	256
18.9.1	tsc	-r source-map-support/register	❌	266
18.9.1	tsc			119

[hildjj]

I started a doc here: https://github.com/hildjj/source-map-architecture

Please open issues there and send PRs.