Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Source maps sources are relative to root instead of to .map file #1255

Closed
jsedlacek opened this issue Dec 6, 2020 · 13 comments · Fixed by #1368 or swc-project/cli#42
Closed

Source maps sources are relative to root instead of to .map file #1255

jsedlacek opened this issue Dec 6, 2020 · 13 comments · Fixed by #1368 or swc-project/cli#42
Assignees
Labels

Comments

@jsedlacek
Copy link

Describe the bug

Source map sources are related to root instead of to .map file.

I have source (Typescript) files inside the src folder and generate (javascript) into the build folder using:

yarn swc src -d build -s true

The build/index.js.map contains:

{
  "version": 3,
  "sources": [
    "src/index.ts"
  ],
...

When compiled via tsc, the result is:

{
  "version": 3,
  "file": "index.js",
  "sourceRoot": "",
  "sources": [
    "../src/index.ts"
  ],
  ...

Input code

src/index.ts:

console.log('Hello');

Config

{}

Expected behavior

The source reference is relative to the .map file.

Version

The version of @swc/core: 1.2.40

Additional context

Because of this, the VS Code is not able to add a breakpoint in the .ts file when debugging.

@jsedlacek jsedlacek added the C-bug label Dec 6, 2020
@kdy1 kdy1 added this to the v1.2.47 milestone Jan 25, 2021
kdy1 added a commit to kdy1/swc that referenced this issue Jan 29, 2021
@kdy1 kdy1 self-assigned this Jan 29, 2021
kdy1 added a commit that referenced this issue Jan 29, 2021
swc_ecma_parser:
 - Fix generic parsing issue in jsx context. (#1299)

swc_ecma_transforms_module:
 - Allow importing a module multiple time. (#1232)
 - Handle imports in the constructor of an exported class decl. (#1213)

swc:
 - Respect `sourceMappingURL`. (#1236)
 - Resolve `sourceMappingURL` relative from file. (#1255)
 - Respect `isModule: false` (#1258)

spack:
 - Support loading json files. (#1225)
@jsedlacek
Copy link
Author

@kdy1 Is this fixed in version 1.2.47? I just tried it, and the bug seems to be present there.

@kdy1
Copy link
Member

kdy1 commented Feb 1, 2021

@jsedlacek Hmm... I thought I fixed it, but maybe I made a mistake.

@kdy1 kdy1 reopened this Feb 1, 2021
@kdy1 kdy1 modified the milestones: v1.2.47, v1.2.48 Feb 1, 2021
@kherock
Copy link

kherock commented Feb 11, 2021

This is due to a combination of #1388 and the CLI package not using the cwd option when an output directory is specified. I'm working on a PR fixing this in the CLI, but I haven't learned Rust yet and probably can't fix #1388 on my own.

@kdy1 kdy1 modified the milestones: v1.2.48, v1.2.49 Feb 19, 2021
@kdy1 kdy1 modified the milestones: v1.2.49, v1.2.50 Feb 23, 2021
@kdy1 kdy1 modified the milestones: v1.2.50, v1.2.51 Mar 3, 2021
@kdy1 kdy1 modified the milestones: v1.2.51, v1.2.52 Mar 28, 2021
@kdy1 kdy1 removed their assignment Mar 29, 2021
@kdy1 kdy1 modified the milestones: v1.2.52, v1.2.53, v1.2.54 Apr 10, 2021
kdy1 added a commit to kdy1/swc that referenced this issue Apr 19, 2021
@kdy1
Copy link
Member

kdy1 commented Apr 19, 2021

I found that being relative to the output source file requires knowing the destination path of sourcemap.
But it has some problems.

  • For inline sourcemaps, destination path may not exist at all.

tsc is a bit different, as it always emit to file.

  • For .map files, we need to pass down some parts of cli options to transform and print so that the swc crate can know the destination path.

This seems like a bad design. The function named print accepting the destination path without printing to the path is strange.

I'll postpone this issue to think about it more.

@kdy1 kdy1 removed this from the v1.2.54 milestone Apr 19, 2021
@kdy1 kdy1 modified the milestones: v1.2.60, v1.2.61 Jun 7, 2021
@kdy1 kdy1 modified the milestones: v1.2.61, v1.2.62 Jun 16, 2021
@kdy1 kdy1 mentioned this issue Jun 18, 2021
10 tasks
@kdy1 kdy1 modified the milestones: v1.2.62, v1.2.63 Jun 27, 2021
@kdy1 kdy1 modified the milestones: v1.2.63, v1.2.64 Jul 5, 2021
@pbadenski
Copy link

@kdy1 Apologies for being a bit impatient... Any updates on this, any way I could help? This is the remaining big reason we're holding off to move our project over from babel to swc :(

@kdy1
Copy link
Member

kdy1 commented Jul 7, 2021

@pbadenski
I'll look into this. This seems a bit complex, though.

kdy1 added a commit to kdy1/swc that referenced this issue Jul 8, 2021
kdy1 added a commit that referenced this issue Jul 8, 2021
swc:
 - Use `output_path` to make sourcemap path relative to the `.map` file. (#1255)
@kdy1
Copy link
Member

kdy1 commented Jul 9, 2021

This will be fixed as of v1.2.64
I need to patch cli to detect the version of swc core and pass some more options for v1.2.64+

@kdy1 kdy1 self-assigned this Jul 9, 2021
@kdy1 kdy1 modified the milestones: v1.2.64, v1.2.65, v1.2.66, v1.2.67 Jul 14, 2021
@kdy1 kdy1 removed this from the v1.2.67 milestone Jul 21, 2021
@pbadenski
Copy link

Is there anything special I need to have this work with @swc/register? I just tried on @swc/core#v1.2.70 and debugging still doesn't work in my WebStorm (where it works fine with babel).

I tried both sourceMaps: true and sourceMaps: "inline" in my .swcrc.

The difference seems to be that source map in babel is:

...
"sourceRoot": "/Users/pbadenski/workspace/ui/tests/unit/formula/engine/",
"sources": [
    "evaluatorV1.spec.ts"
  ],
...

and in swc it's:

...
"sources": [ "/Users/pbadenski/workspace/ui/tests/unit/formula/engine/evaluatorV1.spec.ts"
  ],
...

@kdy1
Copy link
Member

kdy1 commented Aug 3, 2021

I think it's an issue of @swc/register. I'll take a look when current task is finished.

@pbadenski
Copy link

Correction - it looks like this works now, but lines aren't correct in the source maps, I'll submit a separate issue for that.

@swc-bot
Copy link
Collaborator

swc-bot commented Oct 23, 2022

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.

@swc-project swc-project locked as resolved and limited conversation to collaborators Oct 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

Successfully merging a pull request may close this issue.

5 participants