The logic behind sort_reexports was keeping track of a point in the output_stream, and seeked to that point before writing the sorted reexports back in, in order to compensate for the first line of this code sorting section being written into the stream already.
The original code tried to track the position of the point with every iteration, but since the code is very branched, and contains ~10 .write statements, this fails, and this approach would never be easily maintained. So I opted to simplify the approach by instead rolling back the write position in the stream by the length of the segment that was written too much.
Additionally, when the input code sort section is longer than the sorted output (e.g., when there is a lot of trimmed whitespace), some previously written garbage remained, which I fixed by truncating the stream after writing to it during sort_reexport operations.
Fixes #2193 and fixes #2252,
The logic behind
sort_reexports
was keeping track of a point in theoutput_stream
, and seeked to that point before writing the sorted reexports back in, in order to compensate for the first line of this code sorting section being written into the stream already.The original code tried to track the position of the point with every iteration, but since the code is very branched, and contains ~10
.write
statements, this fails, and this approach would never be easily maintained. So I opted to simplify the approach by instead rolling back the write position in the stream by the length of the segment that was written too much.Additionally, when the input code sort section is longer than the sorted output (e.g., when there is a lot of trimmed whitespace), some previously written garbage remained, which I fixed by truncating the stream after writing to it during
sort_reexport
operations.