Skip to content

Sourcemap path in current bundle isn't being formed properly #14021

Closed as not planned

Description

@JSMike

I'm submitting a ... (check one with "x")

[ x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
Sourcemaps are being added to each angular bundle from the perspective of the wrong directory. These sourcemaps are currently included in the latest (2.4.4) release when doing a fresh npm install.

Example from node_modules/@angular/core/src/linker/compiler.js.map

{"version":3,"file":"compiler.js","sourceRoot":"","sources":["../../../../../modules/@angular/core/src/linker/compiler.ts"],"names":[],

This is causing an unexpected/incorrect path to be displayed in debugging tools.

Expected behavior
Sourcemap paths should start from the npm repository's base directory. In this case the path should start from modules/@angular/core

Resulting in a path similar to this:

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

Minimal reproduction of the problem with instructions

Create a new project with Angular CLI beta.25-5

modify the file: node_modules/angular-cli/models/webpack-build-common.js:132

replace exclude: [nodeModules] with exclude: /node_modules\/(?!(\@angular\/core)).*/

*note: this is just to quickly include sourcemaps for @angular/core

run ng serve

Open the served page in Chrome and use developer tools > Sources tab
As a result (when using webpack) files appear to be in:

webpack://../../../../../modules/@angular/core/src/linker/compiler.ts

instead of

webpack://./~/@angular/core/src/linker/compiler.ts

What is the motivation / use case for changing the behavior?
Debugging Angular codebase from the context of a CLI project (I'm assuming whenever using webpack).

Please tell us about your environment:

OSX, VSCode, NPM, Webpack Dev Sever

  • Angular version: 2.0.X

2.4.4

  • Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Chrome, I haven't tried others

  • Language: [all | TypeScript X.X | ES6/7 | ES5]
    TypeScript

  • Node (for AoT issues): node --version =
    angular-cli: 1.0.0-beta.25.5
    node: 6.5.0
    os: linux x64
    @angular/common: 2.4.4
    @angular/compiler: 2.4.4
    @angular/core: 2.4.4
    @angular/forms: 2.4.4
    @angular/http: 2.4.4
    @angular/material: 2.0.0-beta.1
    @angular/platform-browser: 2.4.4
    @angular/platform-browser-dynamic: 2.4.4
    @angular/router: 3.4.4
    @angular/compiler-cli: 2.4.4

Also note, I believe that webpack may be having issues with the sourcemaps plugin for scoped npm packages (anything @username/project) it's not placing the sources in the correct location even when the sourcemaps are corrected.

Activity

  1. JSMike commented on Jan 22, 2017

    @JSMike
    Author

    I did some digging, it has to do with tools/@angular/tsc-wrapped/src/main.ts.
    specifically:

    • the cwd() / projectDir / basePath when main.ts is called by build.sh ( ${TSC} ),
    • the destination of the build files.
    • the values of the rootDir, mapRoot, (and maybe baseUrl?) in the tsconfig-build.json for each module

    I tried a few combinations but I didn't have much luck. If I can find more time to work on this I will, but I'm very busy the next couple of weeks. If someone else wants to give it a shot, you can use the following command from the package root and attach a listener in vscode to step through the process.

    node --max-old-space-size=3000 --debug-brk dist/tools/@angular/tsc-wrapped/src/main -p `pwd`/modules/@angular/core/tsconfig-build.json
    

    the output files can then be found in dist/packages-dist/core

  2. DzmitryShylovich commented on Mar 25, 2017

    @DzmitryShylovich
    Contributor

    @JSMike is this still valid in ng4?

  3. JSMike commented on Mar 27, 2017

    @JSMike
    Author

    @DzmitryShylovich yes, this is still an issue. It actually looks significantly worse in ng4 since the files being used are the bundled .es5.js ones and not the individual js files.

    I've been digging into this a bit when I have free time. I had some success with Angular 2.x by making some changes to the build tsconfig and modifying the generated .map files, but so far I've only gotten it to work by including the .ts files with the bundle to be the target. Chrome doesn't appear to be using the "sourcesContent" that's included in the .map files for some reason, i'm not sure if that's limited to this issue or not.

    I haven't had much time to look into this lately, I was hoping to find some people at ng-conf that want to hack away at this with me :)

  4. JSMike commented on Mar 27, 2017

    @JSMike
    Author

    Having issues looking for a solution right now because of this: #15527 when trying to use ngc

  5. added
    area: packagingIssues related to Angular's creation of npm packages
    on Apr 10, 2017
  6. IgorMinar commented on Dec 22, 2017

    @IgorMinar
    Contributor

    somewhat related issue: #19841

  7. added this to the Backlog milestone on Jan 23, 2018
  8. JoostK commented on Mar 14, 2020

    @JoostK
    Member

    This is definitely still an issue, although the source path is slightly different:

    @devversion are you aware of any change from 8.0 to 9.0 in the Bazel stuff that could have caused the change?

  9. devversion commented on Mar 14, 2020

    @devversion
    Member

    @JoostK I'm not aware of any change from v8 to v9 that could cause these invalid source map paths.

    I checked whether 9581658 caused any regression (sine it's path generation related), but looks like it didn't change anything unexpectedly. angular/core-builds@f4cf44d. I can double-check if I find something, but I remember some source map paths being broken for quite some while (even in v8 IIRC) when I created the size-tracking tool.

  10. IgorMinar commented on Jun 1, 2020

    @IgorMinar
    Contributor

    This is still broken in @angular/[email protected]

  11. added
    P3An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
    and removed on Oct 1, 2020
  12. petebacondarwin commented on Oct 19, 2020

    @petebacondarwin
    Contributor

    Keeping this as the primary tracking issue for problems related to the sources paths in the source-maps generated by the Angular build. Related issues that are tracked here:

  13. removed their assignment
    on Jan 17, 2021
  14. JeanMeche commented on Sep 16, 2025

    @JeanMeche
    Member

    Without further reports in the last 5 years, I'll consider this issue closed.

  15. angular-automatic-lock-bot commented on Oct 17, 2025

    @angular-automatic-lock-bot

    This issue has been automatically locked due to inactivity.
    Please file a new issue if you are encountering a similar or related problem.

    Read more about our automatic conversation locking policy.

    This action has been performed automatically by a bot.

  16. locked and limited conversation to collaborators on Oct 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3An issue that is relevant to core functions, but does not impede progress. Important, but not urgentarea: packagingIssues related to Angular's creation of npm packagesfreq4: criticalstate: confirmedtype: bug/fix

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions