Lots of whitespace differences introduced by endo bundler
See original GitHub issueOn the right is the original lockdown-shim.js
. On the left is the corresponding portion of lockdown.umd.js
aligned for a visual line by line comparison. There are lots of little divergences. I do not remember seeing these divergences when we were using some previous bundler (rollup?).
These differences will impede the debugging experience. It means that at least the columns are different, and so we cannot simply sourceURL the original source file to appear in the debugger in lieu of the bundled source.
Issue Analytics
- State:
- Created 2 years ago
- Comments:9 (6 by maintainers)
Top Results From Across the Web
Quick Tip: How to Hide Whitespace Changes in Git Diffs
GitLab. You can hide whitespace changes for GitLab diffs in two ways. First, click the “Hide whitespace changes” button near the top of...
Read more >Git compare window shows that everything has changed in ...
Git compare window shows that everything has changed in the file when "Ignore trim whitespace" is unchecked.. PZPéter Zsolt.
Read more >File diffs always show whitespace changes - EGit / JGit - Eclipse
Anytime I diff a file within Eclipse against any version from my Git repository, the comparison always shows whitespace changes, ...
Read more >Git add everything but whitespace changes | by Robin Kim
I tried to use git add -p to tell git which whitespace edits to ignore, but it just wasn't feasible to parse through...
Read more >tPR - River Thames Conditions - Environment Agency - GOV.UK
Bergaduh di low yat, How did king saul's reign end, 11x14 portfolio binder, ... Shortbread butter cookies difference, Child of light trophies, Hasil...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Actually, the current babel output seems to differ on more than whitespace, for example unnecessary parens, so that a correspondence verifier for babel output is no longer such a trivial exercise. This pushes harder for us to convert to CSTs.
Thanks! If the cst works (it looks like a great find!), I prefer it to the sourcemap path. With sourcemaps, the programmer is often looking at their original source text which can differ from the code actually being executed in devious ways. Even with the cst, I’d expect programmers to often be looking at their original source test, via sourceURL rather than text being executed. But, since these are supposed to differ only on
import
andexport
,import
andexport
can be trivially caught by a diff.CST FTW! Thanks much. I hope this works!
All that said, if we do sourcemaps, we can easily write a checker to ensure that the pre vs post source text differs only on
import
,export
, and whitespace. We should probably do that anyway. Once that’s verified, debugging through a sourcemap view would be safe.