New counting strategy

[danvk]

Fixes #47
Closes #57

Sorry this has taken so long! See this comment for an explanation of why I think this is a good strategy.

@ersimont @dmitrysteblyuk would love your input.

[danvk]

I'll give folks another 24h to comment and then merge/release this.

[dmitrysteblyuk]

@danvk thank you for the great job! Now it's much much better. The displayed total size is bit bigger than the actual one by few kB, but it's alright. It used to show much smaller size which caused an illusion that minifiers did a good job.

[ersimont]

My personal opinion: it should not be the role of this library to "fix" the output of the underlying source map info. I would rather see this library output a separate value for all the "nulls", rather than trying to assign them to a non-null source. Then, if that is undesirable, the underlying libraries could/should be changed so that they attribute those sections to a proper source.

As it is, this feels like a mixing of concerns. And more than that, it seems like experimentation to guess where we think these null values should go based on limited experiments. But e.g. who is to say, if some null values appear between two different sources, whether they should always belong to the one before it or after it? Those kinds of rules seem brittle -- dependent on the internals of the minifiers AND source mappers.

[ersimont]

I should add: I can see the other side of the argument - that it would be nicer for users to see output with good guesses for where those null values should belong. I'm not trying to say it would be a huge mistake or anything - but I did want to raise the idea in case it also made sense to you. I don't know anything about the underlying source map libraries - whether they are actively maintained, whether they could be change to "fix" the null output, or whether there is good reason for it to be null and should stay that way. But in that last case, those same reasons might apply to this tool, too?

Anyway, thank you for continuing to show this tool love. It is a great tool!

[danvk]

@ersimont you've convinced me. The null mappings are TypeScript's problem, not source-map-explorer's.

The new approach is really simple: each byte is mapped and counted against its source file. An additional <unmapped> source is added to cover the unmapped bytes. The fraction of unmapped bytes gets logged (to stderr) after every invocation:

$ source-map-explorer foo.js
Unable to map 158 / 123156 bytes (0.13%)

This may not match the file size because of newlines, but @kara has expressed interest in cleaning that up.

I'll merge & release this tonight if there are no objections.

[danvk]

Released as 1.5.0.