feat: Add debug_id field to SourceMapIndex
#117
Conversation
Also, add support for encoding and decoding the new `debug_id` field, and add tests. In order to be able to more thoroughly test encoding/decoding, this code adds `PartialEq` and `Debug` implementations to some structs which were lacking it previously. Closes #113
| @@ -214,7 +214,8 @@ impl Encodable for SourceMapIndex { | |||
| x_metro_module_paths: None, | |||
| x_facebook_sources: None, | |||
| debug_id: None, | |||
| _debug_id_new: None, | |||
| // Put the debug ID on _debug_id_new to serialize it to the debugId field. | |||
There was a problem hiding this comment.
This behavior differs from the other cases—we don't write the _debug_id_new/debugId field anywhere, it's only used for reading. I would suggest doing the same here and switching to the new field in a separate PR.
There was a problem hiding this comment.
You mean I should switch everything over to writing to the debugId field in the separate PR?
The reason I am reluctant to do that is because it would likely require a new major release of the crate (and then also in the CLI), since we would break anyone who relies on SourceMap objects being written to the debug_id field. On the other hand, since we are only just now adding the ability to write a debug ID field for SourceMapIndex, it is not a breaking change to write to debugId/_debug_id_new.
It would, however, in my opinion be beneficial to use the debugId field already here, since that is what we want to move towards, anyways
There was a problem hiding this comment.
Alright, that makes sense.
Also, add support for encoding and decoding the new
debug_idfield, and add tests.In order to be able to more thoroughly test encoding/decoding, this code adds
PartialEqandDebugimplementations to some structs which were lacking it previously.Closes #113