You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firstly - great job on swc, today was the first time we had used it and it really is very very fast! 馃槉
Today we discovered that swc source maps are missing end ranges for multi-line blocks, which causes problems for various developer tooling the relies on source maps, including istanbul.js and our product, Wallaby.js.
While source maps are lossy by nature, most source maps include a mapping for the end range of certain types of ast nodes (e.g. ExpressionStatements). These appear to be missing for swc source maps which breaks JavaScript developer tooling that relies on these.
After identifying the problem, we have used https://sokra.github.io/source-map-visualization/#custom to visualize the problem for you and have compared swc, Babel and TypeScript (see below). You will see in the swc source maps, there is no mapping after throw new Error('boom'); while there is for TypeScript and Babel.
swc
TypeScript
Babel
We have also provide the sample repo that you can use to generate the transformed files and their source maps (refer to package.json scripts).
Is this by design or a bug? If it is by design, what is your guidance to determine source-code mapping for end-of-range for swc transformed files (e.g. we have the original source file + line + column after at the end of the file)? From a development tooling perspective, it would be ideal if the source maps would behave similarly to either Babel or TypeScript if at all possible.
The text was updated successfully, but these errors were encountered:
swc_common:
- `SourceMap`: Don't panic for dummy spans.
swc_ecma_codegen:
- Use span for `throw`. (#1685)
- Use span for `var` / `let` / `const`.
- Use span for `new`.
- Use span for `if`.
- Add spans to braces of a block statement. (#1796)
swc_ecma_transforms_compat:
- `parameters`: Don't drop the span of block statements. (#1796)
swc:
- Allow specifying input source map in `.swcrc`.
- Ensure that the inline source map works properly. (#1713)
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
Issue Description / Background
Firstly - great job on
swc
, today was the first time we had used it and it really is very very fast! 馃槉Today we discovered that
swc
source maps are missing end ranges for multi-line blocks, which causes problems for various developer tooling the relies on source maps, including istanbul.js and our product, Wallaby.js.While source maps are lossy by nature, most source maps include a mapping for the end range of certain types of ast nodes (e.g. ExpressionStatements). These appear to be missing for
swc
source maps which breaks JavaScript developer tooling that relies on these.After identifying the problem, we have used https://sokra.github.io/source-map-visualization/#custom to visualize the problem for you and have compared
swc
,Babel
andTypeScript
(see below). You will see in theswc
source maps, there is no mapping afterthrow new Error('boom');
while there is forTypeScript
andBabel
.swc
TypeScript
Babel
We have also provide the sample repo that you can use to generate the transformed files and their source maps (refer to
package.json
scripts).Is this by design or a bug? If it is by design, what is your guidance to determine source-code mapping for end-of-range for
swc
transformed files (e.g. we have the original source file + line + column after at the end of the file)? From a development tooling perspective, it would be ideal if the source maps would behave similarly to either Babel or TypeScript if at all possible.The text was updated successfully, but these errors were encountered: