Last 12 weeks · 0 commits
2 of 6 standards met
crashes with an opaque when called with a zero-length range (): The reason is that for an empty range has no chunk, so is and the subsequent blows up. already short-circuits a zero-length range as a no-op (), so I did the same in — moving nothing has no effect. I found this while fuzzing random valid operation sequences. Added a test alongside the other edge cases; full suite passes.
This is a PR for adding an option for the source map output's hires mode (experimental because the flag relies on a non-finalized source map feature). This new option provides a similar resolution as providing , but uses range mappings to reduce the number of mappings. Range mappings is an in-progress proposal for source maps that we're working on in the source map specification group (TC39-TG4). It would allow mappings to be specified for a whole range of continuous positions at once. This PR is marked as a draft because it uses features from @jridgewell/sourcemap-codec that haven't been released yet. Would be happy to address any feedback about it in its current state though!
(I'm lazy, so description just copied from commits) Just like move (from where the main idea is copied), but keeps the original chunks in place. The implementation currently suffers from one drawback - the new chunks aren't added into the byStart/byEnd indexes - since these index by original location, the index would now have to lead to 2 locations. So if you copy first, then overwrite/append/prepend, the changes are only written in the original location, not on the copied snippet. However, if you do anything before copying, the changes are carried over. Regarding the added test and changes in package.json: In test/dev builds, DEBUG is replaced with true, which runs additional code marking the 'duplicate' chunks created by .copy() with chunk.isCopy. This is detected in integrity checker in tests - these chunks are, as described in previous commit, not included in the indexes, which isn't easy to solve, so these chunks are just excluded from the check. In production code (verified with npm run publish), DEBUG is replaced with false and the code becomes unreachable and is tree-shaked. Why I'm implementing this For - the type-checking (the svelte2tsx step) around is simplified (well, pretty much non-existent), and the copy feature is required for implementing it correctly. I hope this could help other projects as well. Does the resulting source map work I believe so
Repository: Rich-Harris/magic-string. Description: Manipulate strings like a wizard Stars: 2712, Forks: 116. Primary language: JavaScript. Languages: JavaScript (100%), HTML (0%). License: MIT. Latest release: v0.30.21 (8mo ago). Open PRs: 9, open issues: 21. Last activity: 8mo ago. Community health: 42%. Top contributors: Rich-Harris, antfu, mourner, greenkeeperio-bot, TrySound, guybedford, eventualbuddha, sapphi-red, btea, alangpierce and others.