[0.17.0-beta.44] source map has problem ! can't debug ! (0.17.0-beta.42 is okay !! ) #2361

shaoahs · 2017-08-29T08:35:03Z

JSPM Version: 0.17.0-beta.44

Transpiler Plugin(s): babel

Details:
source map has problem ! can't debug ! (0.17.0-beta.42 is okay !! )

command jspm bundle <%= pkg.source %> web/debug/build.js -d --config jspm.build.json --inject

The text was updated successfully, but these errors were encountered:

aluanhaddad · 2017-09-05T22:18:03Z

I will try to take a look at this tonight

guybedford · 2017-09-18T12:04:42Z

@shaoahs is there anyway you can share a replication here?

shaoahs · 2017-09-19T05:39:56Z

create a project. project tree like this

.
├── Gruntfile.js
├── package.json
├── package-lock.json
└── web
    ├── build.js
    ├── build.js.map
    ├── index.html
    ├── jspm.config.js
    └── src
        └── app.js

procedure

jspm init

warn Running jspm globally, it is advisable to locally install jspm via npm install jspm
     --save-dev.

Package.json file does not exist, create it? [Yes]: Yes
Init mode (Quick, Standard, Custom) [Quick]: Quick
Local package name (recommended, optional): app
package.json directories.baseURL: web
package.json configFiles folder [web/]: web/
Use package.json configFiles.jspm:dev? [No]: No
SystemJS.config browser baseURL (optional): ./
SystemJS.config Node local project path [web/src/]: web/src/
SystemJS.config local package main [app.js]: app.js
SystemJS.config transpiler (Babel, Traceur, TypeScript, None) [babel]: babel

Gruntfile.js

module.exports = function(grunt) {
  "use strict";
  var config = {
    browserSync: {
      dev:{
        bsFiles: {
          src : []
        },
        options: {
          watchTask: false,
          server: {
            baseDir: "web"
          }
        }
      }
    }
  };
  grunt.initConfig(config);

  grunt.loadNpmTasks('grunt-browser-sync');
  grunt.registerTask('serve', 'start web server', ['browserSync']);
};

package.json

{
  "jspm": {
    "name": "app",
    "main": "app.js",
    "directories": {
      "baseURL": "web"
    },
    "devDependencies": {
      "plugin-babel": "npm:systemjs-plugin-babel@^0.0.25"
    }
  },
  "devDependencies": {
    "grunt": "^1.0.1",
    "grunt-browser-sync": "^2.2.0",
    "jspm": "0.17.0-beta.45"
  }
}

web/index.html

<html>
  <head>
    <title></title>
    <meta content="">
    <style></style>
  </head>
  <body>
    <script src="jspm_packages/system.js"></script>
    <script src="jspm.config.js"></script>
    <script crossorigin="anonymous">
      SystemJS.import('src/app.js');
    </script>
  </body>
</html>

web/jspm.config.js

SystemJS.config({
  paths: {
    "npm:": "jspm_packages/npm/",
    "app/": "src/"
  },
  browserConfig: {
    "baseURL": "."
  },
  devConfig: {
    "map": {
      "plugin-babel": "npm:[email protected]"
    }
  },
  transpiler: "plugin-babel",
  packages: {
    "app": {
      "main": "app.js",
      "meta": {
        "*.js": {
          "loader": "plugin-babel"
        }
      }
    }
  }
});

SystemJS.config({
  packageConfigPaths: [
    "npm:@*/*.json",
    "npm:*.json"
  ],
  map: {},
  packages: {}
});

web/src/app.js

console.log('hello` world !');

======================================================
then
use this command . is okay.
in browser Source Maps is normal !

jspm bundle src/app.js

use this command . has problem.
in browser Source Maps ! can't see src/app.js

jspm bundle src/app.js --inject

jithine · 2017-09-19T06:48:22Z

I am having the same issue. My project was working fine till 42 beta. After upgrading to 44 & then 45 I find that source maps are blank, even though filename and line numbers are displayed going to the file shows a blank file.

I am bundling like this "jspm bundle src/app.js dist/$npm_package_version/js/bundle.js -wid --source-map-contents

What I see happening is baseUrl for my project files are wrong, they include the entire filesystem path. Attaching a screenshot fro developer tools file explorer.

guybedford · 2017-09-19T07:49:46Z

The source maps PR that was merged most recently was in systemjs/builder#823. It seems like this may have caused the break. We can possibly look at reverting for the next release.

thomas-darling · 2017-09-20T16:22:04Z

@jithin1987 How are you transpiling the code - is it a separate build step, and then you bundle the resulting .js files, or are you using one of the transpiler options in JSPM?
If it is a separate step, what is the sourceRoot in the source maps generated by the transpiler?
And what is sourceRoot it in the source maps generated by the bundler?

My guess is you have an absolute path in there, rooted in a drive letter. Previously such paths were resolved to relative paths when the source maps were generated for the bundle, which could produce some unexpected results with some folder structures - with the recent changes, they are now preserved as absolute, rooted paths. If it's causing issues with the transpilation build into JSPM, then we probably need to change that so such paths are still made relative, but otherwise I'd suggest you switch to using a relative path for sourceRoot when transpiling the files.

Makes sense?

thomas-darling · 2017-09-20T16:33:16Z

@shaoahs Same question for you, what is the sourceRoot it in the source maps generated by the bundler?
Could you maybe post the contents of one of the source maps that don't work? :-)

jithine · 2017-09-20T19:08:06Z

@thomas-darling I am using transpiler options in JSPM using plugin-babel. And I am using inline source maps. Bundle + source maps are generated like this jspm bundle src/app.js dist/$npm_package_version/js/bundle.js -wid --source-map-contents which creates a single transpiled bundle along with sourcemaps in it.

I am not setting sourceRoot anywhere. I don't see it in my jspm.config.js file. I do have this "baseURL": "/" in browserConfig

shaoahs · 2017-09-21T01:05:01Z

I don't know sourceRoot , is mean package.json baseURL or jspm.config.js baseURL or the other
command jspm bundle src/app or jspm bundle src/app --inject
source maps is no changed.
build.js.map

{"version":3,"sources":["/home/shaoahs/html/javascript/proj/test/a01/web/src/app.js"],"names":[],"mappings":";;;;;;AAAA,cAAA,AAAQ,IAAR,AAAY","file":"build.js"}

jithine · 2017-09-26T14:09:22Z

@thomas-darling @guybedford Any updates on this ? This is blocking me from upgrading beyond 0.42 beta. Is this a case of me missing some settings ?
These are my package settings in jspm.config.js

SystemJS.config({
  paths: {
    "npm:": "jspm_packages/npm/",
    "github:": "jspm_packages/github/",
    "project/": "src/"
  },
  browserConfig: {
    "baseURL": "/",
    "bundles": {
      ....
    }
  },
  packages: {
    "project": {
      "main": "./src/client/report.js",
      "meta": {
        "*.js": {
          "loader": "plugin-babel",
          "babelOptions": {
            "plugins": [
              "babel-plugin-transform-react-jsx",
              "babel-plugin-transform-object-rest-spread"
            ]
          }
        }
      }
    }
  }
});

SystemJS.config({
  packageConfigPaths: [
    "npm:@*/*.json",
    "npm:*.json",
    "github:*/*.json"
  ],
  map: {
...

thomas-darling · 2017-09-26T17:10:03Z

I've reproduced the issue using the example provided by @shaoahs, and as suspected, it was caused by that last path.isAbsolute in my previous pull request.

Additionally, the use of path.normalize did not take into account that it might be looking at a file URL, causing it to incorrectly remove two of the / characters in file:///.

The pull request fixes both of those issues - sorry for the inconvenience.

HeinrichFilter · 2017-12-08T07:22:53Z

I'm in the process of upgrading from JSPM beta 32 to latest version, beta 47.

After the upgrade my source maps stopped working.

I'm having the same problem as @jithin1987 had. The files show up empty in Chrome devtools because the source map uses an absolute path which devtools tries to load as http://localhost:8000/Users/MyUsername/project/app/file.js when it should load http://localhost:8000/app/file.js

How do I get it to use the relative path again. @thomas-darling maybe any pointers?

thomas-darling · 2017-12-11T15:45:06Z

@HeinrichFilter
Are you sure you're using the latest version of the SystemJS Builder?
This really should work in 0.16.12.

If you are on the latest version, then I'll be happy to take a look at it, if you can either provide an example that reproduces the issue, or at least some more info about your environment and how you are transpiling, generating source maps, bundling, etc. :-)

Otherwise, the place to debug this is probably around the two lines affected by my pull requests:
https://github.com/systemjs/builder/pull/823/files
https://github.com/systemjs/builder/pull/834/files (this one should have fixed your issue)
Maybe throw some console.log statements in there, in the file installed into your node_modules folder - that might help shed some light on what is happening.

I suspect this might be a configuration problem though, as I'm pretty sure this works correctly now - it's possible that your configuration might technically have been wrong before, in order to work around the bugs that are now fixed. I'll need some more info to help you though :-)

HeinrichFilter · 2017-12-11T16:31:30Z

Thanks @thomas-darling, I appreciate your offer to help!

The one config option that you mention earlier in this thread that I don't see in my project is sourceRoot. Should I set that in my package.json, jspm.config.js or somewhere else? And what should it be set to?

it's possible that your configuration might technically have been wrong before, in order to work around the bugs that are now fixed.

I suspect it is very likely that this is the case

Commands that I ran to upgrade:

$ rm -rf node_modules/
$ rm -rf jspm_packages/
//change package.json to "jspm": "^0.17.0-beta.47"
$ yarn install
$ jspm --version
   0.17.0-beta.47
   Running against local jspm install.
$ yarn list --pattern systemjs-builder
   yarn list v1.3.2
   └─ [email protected]
   ✨  Done in 0.70s.
$ jspm install
$ jspm bundle app/index.js -d
   ok   Built into build.js with source maps, unminified.

At this stage when I open build.js.map in a text editor it is full of references to the absolute paths of my files e.g. /Users/MyUsername/project/app/file.js. As mentioned, this results in an empty file when opening it in Chrome devtools since Chrome tries to load the source from http://localhost:8000/Users/MyUsername/project/app/file.js

jspm.config.js: (Note the two calls to SystemJS.config(). Is that normal?)

SystemJS.config({
  warning: true,
  paths: {
    "npm:": "jspm_packages/npm/",
    "github:": "jspm_packages/github/",
    "local:": "jspm_packages/local/",
    "app/": "app/"
  },
  browserConfig: {
    "baseURL": "/"
  },
  devConfig: {
     ...//Do you need these parts too?
  },
  transpiler: "plugin-babel",
  packages: {
    "app": {
      "main": "index.js",
      "format": "esm",
      "meta": {
        "*.js": {
          "babelOptions": {
            "stageOne": true,
            "presets": [
              "babel-preset-react",
              "babel-preset-flow"
            ],
            "plugins": [
              "babel-plugin-transform-decorators-legacy"
            ]
          },
          "loader": "plugin-babel"
        }
      }
    }
  },
  meta: {}
});

SystemJS.config({
  packageConfigPaths: [
    "npm:@*/*.json",
    "npm:*.json",
    "github:*/*.json",
    "local:*.json"
  ],
  map: {
     ...//Do you need these parts too?
  },
  packages: {
    ...//Do you need these parts too?
  }
});

package.json:

Is this enough info or do you need something else?

thomas-darling · 2017-12-11T17:27:56Z

Hmm, that looks about right, although I have to say, I'm also fairly new to JSPM 0.17 configuration.
Oh, and the two config calls are normal - #1908

Could you maybe try putting some log statements in there, so we can see what is happening?
I'm thinking something like this:

Insert on line https://github.com/systemjs/builder/blob/master/lib/sourcemaps.js#L52

console.log('-----------------------------------------');
console.log('source:', map.sources[i]);
console.log('sourceRoot:', map.sourceRoot);
console.log('isAbsoluteOrFileUrl:', isAbsoluteOrFileUrl);
console.log('-----------------------------------------');

Insert on line https://github.com/systemjs/builder/blob/master/lib/sourcemaps.js#L114

console.log('-----------------------------------------');
console.log('outPath:', outPath);
console.log('basePath:', basePath);
console.log('source:', source);
console.log('isRootRelative:', isRootRelative);
console.log('-----------------------------------------');

You can just hack those into your node_modules/systemjs-builder/lib/sourcemaps.js file.

I just need a single sample for one of the paths that end up being absolute - not the complete dump :-)

HeinrichFilter · 2017-12-11T21:20:38Z

I've added the suggested logs.

L52 logging is never reached. Upon further investigation it is because sourceMapContents is always set to false for me.

L114: Following is the console output for an external lib (which show up in Chrome devtools BTW) and for one of our project files:
[EDIT: fixed console logs which I initially placed between line 107 & 108 by mistake]

-----------------------------------------
outPath: /Users/heinrichfilter/dev/irp/vrps-web/frontend/public
basePath: /Users/heinrichfilter/dev/irp/vrps-web/frontend/public/
source: jspm_packages/npm/[email protected]/lib/index.js
isRootRelative: false
-----------------------------------------
-----------------------------------------
outPath: /Users/heinrichfilter/dev/irp/vrps-web/frontend/public
basePath: /Users/heinrichfilter/dev/irp/vrps-web/frontend/public/
source: /Users/heinrichfilter/dev/irp/vrps-web/frontend/public/app/vrp-theme.js
isRootRelative: true
-----------------------------------------

I'll also dig a bit deeper but I hope you recognise something since you've worked with the code before.

thomas-darling · 2017-12-11T22:20:39Z

This is interesting - am I correct in assuming you’re not on a Windows machine?
Because looking at this, I think the problem might be, that the fromFileURL function called on line 109 is removing the first 8 characters if the OS is Windows, but only the first 7 if it’s not. That would mean, that on a non-Windows machine, it would end up as an absolute path, and thus be returned as-is, where previously it was always made relative.

Now, the question is why fromFileURL behaves in such an inconsistent way - do those file URL’s look different on UNIX? I have no idea, and I don’t have a UNIX machine around right now, so can’t test it - but maybe @guybedford can shed some light on this?

I would like to think that the correct fix here would be to make fromFileURL behave consistently, but a quick search reveals that it is used in a few other places, and I’m not sure I can guarantee that such a change won’t break something else - I just don’t know this code well enough.
Instead, we should probably just add a condition here, to make sure file URL’s are always made relative, exactly as before - I just didn’t catch this in my testing, as that was only on Windows.

@HeinrichFilter
Can you confirm that you are not on Windows, and that fromFileURL does in fact return an absolute path, as suspected?

@guybedford
What’s your thoughts on the inconsistency in that fromFileURL function, assuming that is the issue?

HeinrichFilter · 2017-12-11T22:33:10Z

Yes, I'm developing on Mac and building/CI/deploying on Ubuntu.

And yes, I was stepping through the code and it is returning an absolute path after the fromFileURL() call.

I still don't quite understand in which case the paths shouldn't be converted to relative paths? Could you explain the reasoning why you added the isRootRelative check?

To be clear, for my case, I would want the files to be converted to relative paths here.

thomas-darling · 2017-12-11T22:51:52Z

Thought so - I’ll prepare a pull request to fix this tomorrow :-)

The previous pull requests were to fix a couple of different issues, one of which was an issue, where if you bundled files that had already been transpiled, and thus already had accompanying source map files, then any root-relative source paths in those source maps would become messed up. Basically, if you already have a source map file with root-relative source paths, then it should just use those as-is.

Your scenario is a bit different, as you are using the built in transpiler, and that use case seemed to work correctly before my pull requests. Hopefully this will be the last issue with this though - I tested it pretty thoroughly last time - just didn’t realize the behavior was different on UNIX.

ArmorDarks · 2018-03-11T16:34:05Z

Strangely enough, I'm on Windows machine and still having the same issue.

SystemJS v0.20.19 Dev
JSPM 0.17.0-beta.47

My paths in source maps file looks like so:

"../../../source/scripts/utils/file:/J:/Work/Someapp/github/source/scripts/utils/someUtil.js"

Here is my jspm.config.js:

SystemJS.config({
  baseURL: "/source/scripts",
  browserConfig: {
    "paths": {
      "npm:": "/jspm_packages/npm/",
      "github:": "/jspm_packages/github/",
      "main/": "",
      "@data": "/temp/data/scripts.json"
    }
  },
  nodeConfig: {
    "paths": {
      "npm:": "jspm_packages/npm/",
      "github:": "jspm_packages/github/",
      "main/": "source/scripts/",
      "@data": "temp/data/scripts.json"
    }
  },
  devConfig: {...},
  meta: {
    "@data": {
      "loader": "json"
    },
    "*.vue": {
      "loader": "systemjs-plugin-vue"
    }
  },
  transpiler: "plugin-babel",
  packages: {
    "main": {
      "main": "main.js",
      "format": "esm",
      "meta": {
        "*.js": {
          "loader": "plugin-babel"
        },
        "*.json": {
          "loader": "json"
        }
      }
    }
  },
  map: {
    "@hot": "@empty",
    "json": "npm:[email protected]"
  }
});

SystemJS.config({
  packageConfigPaths: [
    "npm:@*/*.json",
    "npm:*.json"
  ],
  map: {
    "babel-polyfill": "npm:[email protected]",
    "fs": "npm:[email protected]",
    "moment": "npm:[email protected]",
    "numbro": "npm:[email protected]",
    "path": "npm:[email protected]",
    "process": "npm:[email protected]",
    "smart-plurals": "npm:[email protected]",
    "tcomb": "npm:[email protected]",
    "vue": "npm:[email protected]",
    "vue-router": "npm:[email protected]",
    "vue-slider-component": "npm:[email protected]",
    "vuex": "npm:[email protected]"
  },
  packages: {
    "npm:[email protected]": {
      "map": {
        "regenerator-runtime": "npm:[email protected]",
        "core-js": "npm:[email protected]",
        "babel-runtime": "npm:[email protected]"
      }
    },
    "npm:[email protected]": {
      "map": {
        "regenerator-runtime": "npm:[email protected]",
        "core-js": "npm:[email protected]"
      }
    },
    "npm:[email protected]": {
      "map": {
        "bignumber.js": "npm:[email protected]"
      }
    }
  }
});

aluanhaddad · 2018-03-11T21:22:20Z

@ArmorDarks weirdly enough I've been seeing this on Windows as well but only when using TypeScript as my transpiler. If I use Babel everything works as expected.

ArmorDarks · 2018-03-12T22:22:47Z

I've created an empty project and inited it with JSPM 0.17.0-beta.47 jspm init quick default settings.

I've received same broken paths:

{"version":3,"sources":["src/file:/J:/_DEL_JSPM_TEST/src/app.js"],"names":[],"mappings":";;;;;;AAAA,QAAQ","file":"build.js"}

The problem seems to vanish when I remove plugin-babel loader

{"version":3,"sources":["src/app.js"],"names":["console","log"],"mappings":";;;;;;;;;AAAAA,YAAQC,GAAR","file":"build.js"}

So, it seems to be somehow connected to plugin-babel or maybe loaders in general.

My guess that it's caused not exactly by plugin-babel, but loaders handling, because I'm receiving same broken paths in other loaders, like the SystemJS loader for Vue.

Here is test case I've used at Dropbox.

thomas-darling · 2018-03-13T07:40:18Z

I just got back from a month in Thailand, so I’m a bit busy catching up to other things, and won’t have time to look into this right now.

I noticed one thing though - the incorrect source paths posted here all seem to contain a part starting with “file:/“, but the function testing whether it is a file URL test for “file:///“ - note the different number of “/“.

I’m guessing, that because of that, the path is probably not be recognized as a file URL, which would explain why it ends up being concatenated with the base URL.

Now, I don’t believe I messed with that function in any of my earlier pull requests, so that would make this a separate bug.

I don’t know why the function is testing for exactly “file:///“ - I’d day a test for just “file:” should be enough, and that would likely fix the bug.
Otherwise, if there is a reason for the more explicit test, I guess the problem has to be in the code producing those non-matching file URLs to begin with :-)

As I said, I won’t have time to look deeper into this right now, so someone else will have to take it from here :-)

ArmorDarks · 2018-04-11T19:35:38Z

@guybedford maybe this issue should be reopened?

ArmorDarks · 2018-04-12T12:51:54Z

The issue seems to be coming not from the file protocol check in SystemJS builder isFileURL function.

I've tried to log paths there, and SystemJS builder isFileURL already receiving wrong paths from map.sources

Here what I've got:

file:///J:/test-project/scripts/modules/file:/J:/test-project/scripts/modules/user.js
file:///J:/test-project/scripts/file:/J:/test-project/scripts/store.js

I've been able to trace issue to the Builder.prototype.buildStatic, where paths seem to be ok before rollupTree function. Here is a content of the inlinedTree

inlinedTree { 'main/main.js':
   { name: 'main/main.js',
     path: 'source\\scripts\\main.js',
     metadata:
      { loader: 'file:///J:/Work/Greencard/green-card-app/jspm_packages/npm/[email protected]/plugin-babel.js',
        babelOptions: [Object],
        loaderModule: [Object],
        scriptLoad: false,
        deps: [],
        timestamp: undefined,
        format: 'esm',
        sourceMap: [Object],
        ast: undefined,
        entry: undefined,
        builderExecute: undefined,
        parseTree: undefined },
     deps: [ './store/store' ],
     depMap: { './store/store': 'main/store/store.js' },
     source: 'import store from \'./store/store\';',
     fresh: true,
     timestamp: 1523531631320,
     configHash: '4f19d831f5506135d356463d5b9d1f2e',
     plugin: 'npm:[email protected]/plugin-babel.js',
     runtimePlugin: false,
     pluginConfig: null,
     packageConfig: null,
     isPackageConfig: undefined,
     deferredImports: null,
     compactedLoads: null },
  'main/store/store.js':
   { name: 'main/store/store.js',
     path: 'source\\scripts\\store\\store.js',
     metadata:
      { loader: 'file:///J:/Work/Greencard/green-card-app/jspm_packages/npm/[email protected]/plugin-babel.js',
        babelOptions: [Object],
        loaderModule: [Object],
        scriptLoad: false,
        deps: [],
        timestamp: undefined,
        format: 'esm',
        sourceMap: [Object],
        ast: undefined,
        entry: undefined,
        builderExecute: undefined,
        parseTree: undefined },
     deps: [ './modules/user' ],
     depMap: { './modules/user': 'main/store/modules/user.js' },
     source: '\n\nimport user from \'./modules/user\';\n\nexport default new Vuex.Store({\n  modules: {\n    user: user\n  }\n});',
     fresh: true,
     timestamp: 1523532579617,
     configHash: '4f19d831f5506135d356463d5b9d1f2e',
     plugin: 'npm:[email protected]/plugin-babel.js',
     runtimePlugin: false,
     pluginConfig: null,
     packageConfig: null,
     isPackageConfig: undefined,
     deferredImports: null,
     compactedLoads: null },
  'main/store/modules/user.js':
   { name: 'main/store/modules/user.js',
     path: 'source\\scripts\\store\\modules\\user.js',
     metadata:
      { loader: 'file:///J:/Work/Greencard/green-card-app/jspm_packages/npm/[email protected]/plugin-babel.js',
        babelOptions: [Object],
        loaderModule: [Object],
        scriptLoad: false,
        deps: [],
        timestamp: undefined,
        format: 'esm',
        sourceMap: [Object],
        ast: undefined,
        entry: undefined,
        builderExecute: undefined,
        parseTree: undefined },
     deps: [],
     depMap: {},
     source: '\n\nexport default { users: users };',
     fresh: true,
     timestamp: 1523532602372,
     configHash: '4f19d831f5506135d356463d5b9d1f2e',
     plugin: 'npm:[email protected]/plugin-babel.js',
     runtimePlugin: false,
     pluginConfig: null,
     packageConfig: null,
     isPackageConfig: undefined,
     deferredImports: null,
     compactedLoads: null } }

But after rollupTree rolledUp.outputs produces wrong sourcemaps paths:

[
  {
    "source": "(function (global, factory) {\n  typeof exports === 'object' && typeof module !== 'undefined' ? factory(exports) :\n  typeof define === 'function' && define.amd ? define(['exports'], factory) :\n  (factory((global.main = global.main || {})));\n}(this, (function (exports) { 'use strict';\n\nvar user = { users: users };\n\nnew Vuex.Store({\n  modules: {\n    user: user\n  }\n});\n\nObject.defineProperty(exports, '__esModule', { value: true });\n\n})));\n",
    "sourceMap": {
      "version": 3,
      "file": null,
      "sources": [
        "file:///J:/Work/Greencard/green-card-app/source/scripts/store/modules/file:/J:/Work/Greencard/green-card-app/source/scripts/store/modules/user.js",
        "file:///J:/Work/Greencard/green-card-app/source/scripts/store/file:/J:/Work/Greencard/green-card-app/source/scripts/store/store.js"
      ],
      "sourcesContent": [
        "\n\nexport default { users }\n",
        "\n\nimport user from './modules/user'\n\nexport default new Vuex.Store({\n  modules: {\n    user\n  }\n})\n"
      ],
      "names": [],
      "mappings": ";;;;;;AAEA,WAAe,EAAE,OAAF;;ICEI,KAAJ;;UAAf;;CAAe;;;;"
    }
  }
]

In ./rollup we can see that bundle.generate already starting to produce wrong filepaths:

{ version: 3,
  file: null,
  sources:
   [ 'main/store/modules/file:/J:/Work/Greencard/green-card-app/source/scripts/store/modules/user.js',
     'main/store/file:/J:/Work/Greencard/green-card-app/source/scripts/store/store.js' ],
  sourcesContent:
   [ '\n\nexport default { users }\n',
     '\n\nimport user from \'./modules/user\'\n\nexport default new Vuex.Store({\n  modules: {\n    user\n  }\n})\n' ],
  names: [],
  mappings: ';;;;;;AAEA,WAAe,EAAE,OAAF;;ICEI,KAAJ;;UAAf;;CAAe;;;;' }

Well, that's where I was able to dig. It seems to be somehow related to Rollup, or the wrong configuration of Rollup on Windows systems.

I've tried to play with Rollup settings in SystemJS builder, and noticed that receives following method:

        load: function(id, options) {
          if (loadList.indexOf(tree[id]) == -1)
            loadList.push(tree[id]);
          loadList.push(tree[id]);
          return {
            code: tree[id].metadata.originalSource || tree[id].source,
            map: tree[id].metadata.sourceMap
          };
        }

where tree[id].metadata.sourceMap.sources for each source contains

[ 'file:///J:/Work/Greencard/green-card-app/source/scripts/main.js' ]
[ 'file:///J:/Work/Greencard/green-card-app/source/scripts/store/store.js' ]
[ 'file:///J:/Work/Greencard/green-card-app/source/scripts/store/modules/user.js' ]

Seems like it is the reason why Rollup in bundle.generate wrongly resolving paths to

sources:
   [ 'main/store/modules/file:/J:/Work/Greencard/green-card-app/source/scripts/store/modules/user.js',
     'main/store/file:/J:/Work/Greencard/green-card-app/source/scripts/store/store.js' ]

I've tried to replace in load method file:/// with '' to achieve following tree[id].metadata.sourceMap.sources content:

[ 'J:/Work/Greencard/green-card-app/source/scripts/main.js' ]
[ 'J:/Work/Greencard/green-card-app/source/scripts/store/store.js' ]
[ 'J:/Work/Greencard/green-card-app/source/scripts/store/modules/user.js' ]

That changed generated source file from non-working

{"version":3,"sources":["../../../source/scripts/store/modules/file:/J:/Work/Greencard/green-card-app/source/scripts/store/modules/user.js","../../../source/scripts/store/file:/J:/Work/Greencard/green-card-app/source/scripts/store/store.js"],"names":[],"mappings":";;;;;;AAEA,WAAe,EAAE,OAAF;;ICEI,KAAJ;;UAAf;;CAAe","file":"main.js"}

to be

{"version":3,"sources":["../../../source/scripts/store/modules/user.js","../../../source/scripts/store/store.js"],"names":[],"mappings":";;;;;;AAEA,WAAe,EAAE,OAAF;;ICEI,KAAJ;;UAAf;;CAAe","file":"main.js"}

Which results in working source maps.

Unfortunately, I'm not sure if that fix a correct approach at all.

Filepaths with fill:///, which are later due to not removed protocol can't be properly resolved, coming from tree and inlinedTree in lib/builder.js, which is a result of a traceExpression and Tracer.

For now, I can't get are tracers returning paths with the protocol on purpose, or it's a bug.

ArmorDarks · 2018-04-12T13:09:32Z

Since it seems to be related to builder and not JSPM itself, I've created systemjs/builder#845

shaoahs changed the title ~~source map has problem ! can't debug ! (0.17.0-beta.42 is okay !! )~~ [0.17.0-beta.44] source map has problem ! can't debug ! (0.17.0-beta.42 is okay !! ) Aug 29, 2017

guybedford mentioned this issue Sep 18, 2017

Fix missing path normalization, causing empty sourcesContent in source maps. systemjs/builder#823

Merged

thomas-darling mentioned this issue Sep 26, 2017

Fix incorrect source path normalization, when the path is either rooted in a drive letter or a file url. systemjs/builder#834

Merged

guybedford closed this as completed in systemjs/builder#834 Oct 9, 2017

thomas-darling mentioned this issue Dec 12, 2017

Fix incorrect source path normalization, when the path is a file URL on a non-Windows system systemjs/builder#837

Merged

ArmorDarks mentioned this issue Mar 14, 2018

Source maps files broken because of not having full path #2167

Closed

ArmorDarks mentioned this issue Apr 12, 2018

Incorrect sourcemap paths on Windows systemjs/builder#845

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[0.17.0-beta.44] source map has problem ! can't debug ! (0.17.0-beta.42 is okay !! ) #2361

[0.17.0-beta.44] source map has problem ! can't debug ! (0.17.0-beta.42 is okay !! ) #2361

shaoahs commented Aug 29, 2017 •

edited

Loading

aluanhaddad commented Sep 5, 2017 •

edited

Loading

guybedford commented Sep 18, 2017

shaoahs commented Sep 19, 2017

jithine commented Sep 19, 2017

guybedford commented Sep 19, 2017

thomas-darling commented Sep 20, 2017 •

edited

Loading

thomas-darling commented Sep 20, 2017

jithine commented Sep 20, 2017

shaoahs commented Sep 21, 2017

jithine commented Sep 26, 2017 •

edited

Loading

thomas-darling commented Sep 26, 2017

HeinrichFilter commented Dec 8, 2017

thomas-darling commented Dec 11, 2017 •

edited

Loading

HeinrichFilter commented Dec 11, 2017 •

edited

Loading

thomas-darling commented Dec 11, 2017

HeinrichFilter commented Dec 11, 2017 •

edited

Loading

thomas-darling commented Dec 11, 2017

HeinrichFilter commented Dec 11, 2017

thomas-darling commented Dec 11, 2017 •

edited

Loading

ArmorDarks commented Mar 11, 2018 •

edited

Loading

aluanhaddad commented Mar 11, 2018

ArmorDarks commented Mar 12, 2018 •

edited

Loading

thomas-darling commented Mar 13, 2018

ArmorDarks commented Apr 11, 2018

ArmorDarks commented Apr 12, 2018

ArmorDarks commented Apr 12, 2018

[0.17.0-beta.44] source map has problem ! can't debug ! (0.17.0-beta.42 is okay !! ) #2361

[0.17.0-beta.44] source map has problem ! can't debug ! (0.17.0-beta.42 is okay !! ) #2361

Comments

shaoahs commented Aug 29, 2017 • edited Loading

aluanhaddad commented Sep 5, 2017 • edited Loading

guybedford commented Sep 18, 2017

shaoahs commented Sep 19, 2017

jithine commented Sep 19, 2017

guybedford commented Sep 19, 2017

thomas-darling commented Sep 20, 2017 • edited Loading

thomas-darling commented Sep 20, 2017

jithine commented Sep 20, 2017

shaoahs commented Sep 21, 2017

jithine commented Sep 26, 2017 • edited Loading

thomas-darling commented Sep 26, 2017

HeinrichFilter commented Dec 8, 2017

thomas-darling commented Dec 11, 2017 • edited Loading

HeinrichFilter commented Dec 11, 2017 • edited Loading

thomas-darling commented Dec 11, 2017

HeinrichFilter commented Dec 11, 2017 • edited Loading

thomas-darling commented Dec 11, 2017

HeinrichFilter commented Dec 11, 2017

thomas-darling commented Dec 11, 2017 • edited Loading

ArmorDarks commented Mar 11, 2018 • edited Loading

aluanhaddad commented Mar 11, 2018

ArmorDarks commented Mar 12, 2018 • edited Loading

thomas-darling commented Mar 13, 2018

ArmorDarks commented Apr 11, 2018

ArmorDarks commented Apr 12, 2018

ArmorDarks commented Apr 12, 2018

shaoahs commented Aug 29, 2017 •

edited

Loading

aluanhaddad commented Sep 5, 2017 •

edited

Loading

thomas-darling commented Sep 20, 2017 •

edited

Loading

jithine commented Sep 26, 2017 •

edited

Loading

thomas-darling commented Dec 11, 2017 •

edited

Loading

HeinrichFilter commented Dec 11, 2017 •

edited

Loading

HeinrichFilter commented Dec 11, 2017 •

edited

Loading

thomas-darling commented Dec 11, 2017 •

edited

Loading

ArmorDarks commented Mar 11, 2018 •

edited

Loading

ArmorDarks commented Mar 12, 2018 •

edited

Loading