Repository navigation
[EPIC] Modernize the crate #71
Description
This crate is pretty old and has a number of outdated/unidiomatic features. For example:
SourceMapBuilder::into_sourcemapshould be calledbuild.SourceMapstores tokens as an unordered vector with a separate ordered index. There is no clear reason tokens can't be stored in an ordered way in the first place (as a vector or BTreeMap).SourceMapstores sources as aVec<String>, but sources may benullin the sourcemap JSON format. This leads tonullsources being replaced with""during parsing, to unclear benefit.SourceMaphas a lot of getter and setter methods that could just as well be replaced with mutable access to the corresponding fields.
Activity
Swatinem commentedon Aug 29, 2023
The crate is also implementing
binary_searchmanually, as well as its own version ofIndexMap.There is also unsafe code related to
SourceView, which is a type that definitely has nothing to do in a genericSourceMapcrate. Similar to how the heuristics-based "find original function name" is very out of place.The problem with the above is that it is still used from the legacy Sentry processor via
symbolic. I would like to kill all that with fire, but I’m unsure about the right time to do so.Swatinem commentedon Aug 29, 2023
I’m also a bit unsure about making all the fields public.
The crate already has a distinction between a raw JSON sourcemap, vs a more concrete type that you can build and manipulate actively.
It might make sense to keep that distinction, but there is an argument to be made to make the concrete type more opaque. But at the same time, having different variants for
SourceMapHermesfor example does make sense, as a sourcemap with thehermes-style extension for scopes does serve a different usecase.[-]Modernize the crate[/-][+][EPIC] Modernize the crate[/+]SourceMapBuilderAPI #85