4 ms·

I recently setup a typescript > webpack project and I was really disappointed with the dev-tools debugging experience. Webpack renames imported bindings, so

I recently setup a typescript > webpack project and I was really disappointed with the dev-tools debugging experience. Webpack renames imported bindings, so import {foo} from './bar'; becomes something like this let __webpack_require_foo_bar = _webpack_modules[5 /* foo */].bar; So if you are paused in the debugger and want to use foo in a watch statement, or use it in a computation you'll have to reference the real source instead of the source maps. I found questions on SO, and it seems like a known and accepted problem, but I know I won't be able to sell my team on Webpack because of this.

deleted 10y ago
[deleted]
johnny_reilly 10y ago
One of the maintainers of ts-loader here. Debugging original source is totally possible. Take a look at the setup here: https://github.com/TypeStrong/ts-loader/tree/master/examples/webpack2-gulp-react-flux-babel-karma https://github.com/TypeStrong/ts-loader/tree/master/examples... And in the official samples (WebPack 1): https://github.com/Microsoft/TypeScriptSamples/tree/master/react-flux-babel-karma https://github.com/Microsoft/TypeScriptSamples/tree/master/r...
- seniorsassycat 10y ago
  So I did reference those examples when I setup this project, but this doesn't have to do with typescript, or ts-loader. Here's some gists showing a minimal reproduction without typescript. https://gist.github.com/anonymous/ad044363f73b845cccb4e7f2259ac398 https://gist.github.com/anonymous/ad044363f73b845cccb4e7f225... Specifically, look at lines 25 and 28 of lib-main.js
  - johnny_reilly 10y ago
    Your WebPack.config.js appears to be missing this: devtool: 'inline-source-map' No sourcemaps, no debugging original source. Hope that helps
    - seniorsassycat 10y ago
      lib-main-dev.js is an example of the output when running 'webpack -d', which is short for '--devtool sourcemap --debug --output-pathinfo', it has the same problem* There are really two problems contributing to this. First, webpack rewrites import/export statments and never introduces a variable binding with the same name as the bindings used in the original import/export. Second sourcemaps _do_ map lines of compiled code to lines of original source, but they _do not_ map renamed variables to original names. As an example, enable minifiaction and soucemaps then try to debug a function. You might notice that the variables are all called a, b, c, and other short uglified strings now. * I just realized that the file I uploaded is missing the ends of each line, so that file is incorrect.
dvcc 10y ago
Doesn't this have more to do with Babel and less to do with Webpack? I think this originates with how Babel treats ES6 Modules differently from CommonJS, and if you were to instead do: const foo = require('./bar').foo it would keep the name the same? EDIT: https://github.com/jamietre/babel-plugin-transform-es2015-modules-commonjs-simple https://github.com/jamietre/babel-plugin-transform-es2015-mo... There is a better explanation with a partial solution.
- seniorsassycat 10y ago
  I don't think Babel is the cause, not in this case. Im using typescript in full es6 mode, module and target are both es6. Babel isn't even in my node_modules.
- jamra 10y ago
  Typescript doesn't need babel since the typescript compiler supports es6.
  - dvcc 10y ago
    The 'let' should have made me re-think the problem.
- deleted 10y ago
  [deleted]
saosebastiao 10y ago
Stuff like this is the reason the Unix Philosophy of small "composable" tools doesn't work in this ecosystem. Because if you run your code through three different preprocessor steps, everything breaks and your source maps aren't even close to usable anymore, so you can't debug anymore. I've been campaigning for more of a monolithic design in the TS ecosystem. Not that the architecture of the TS compiler needs to be monolithic, but rather that TS users should have a blessed and supported stack for everything. We should be able to rely on TS components for linking/packaging, polyfills, optimization, conditional compilation, minification, source map packaging, asset prepackaging and loading, ES6+ standards compliance, etc. But since advocating for anything rhyming with -olith is heresy in the programming world, I'm not confident we'll get there.
- seniorsassycat 10y ago
  This isn't actually caused by piping data through many small tools, it's reproducible with solely webpack 2. https://gist.github.com/anonymous/ad044363f73b845cccb4e7f2259ac398 https://gist.github.com/anonymous/ad044363f73b845cccb4e7f225...
djmashko2 10y ago
This is a big benefit of Meteor's build system - it has several improvements that make debugging more straightforward than with Webpack and default Babel import compilation.

deleted 10y ago

[deleted]

johnny_reilly 10y ago

One of the maintainers of ts-loader here. Debugging original source is totally possible. Take a look at the setup here: https://github.com/TypeStrong/ts-loader/tree/master/examples/webpack2-gulp-react-flux-babel-karma https://github.com/TypeStrong/ts-loader/tree/master/examples... And in the official samples (WebPack 1): https://github.com/Microsoft/TypeScriptSamples/tree/master/react-flux-babel-karma https://github.com/Microsoft/TypeScriptSamples/tree/master/r...

seniorsassycat 10y ago
So I did reference those examples when I setup this project, but this doesn't have to do with typescript, or ts-loader. Here's some gists showing a minimal reproduction without typescript. https://gist.github.com/anonymous/ad044363f73b845cccb4e7f2259ac398 https://gist.github.com/anonymous/ad044363f73b845cccb4e7f225... Specifically, look at lines 25 and 28 of lib-main.js
- johnny_reilly 10y ago
  Your WebPack.config.js appears to be missing this: devtool: 'inline-source-map' No sourcemaps, no debugging original source. Hope that helps
  - seniorsassycat 10y ago
    lib-main-dev.js is an example of the output when running 'webpack -d', which is short for '--devtool sourcemap --debug --output-pathinfo', it has the same problem* There are really two problems contributing to this. First, webpack rewrites import/export statments and never introduces a variable binding with the same name as the bindings used in the original import/export. Second sourcemaps _do_ map lines of compiled code to lines of original source, but they _do not_ map renamed variables to original names. As an example, enable minifiaction and soucemaps then try to debug a function. You might notice that the variables are all called a, b, c, and other short uglified strings now. * I just realized that the file I uploaded is missing the ends of each line, so that file is incorrect.

dvcc 10y ago

Doesn't this have more to do with Babel and less to do with Webpack? I think this originates with how Babel treats ES6 Modules differently from CommonJS, and if you were to instead do: const foo = require('./bar').foo it would keep the name the same? EDIT: https://github.com/jamietre/babel-plugin-transform-es2015-modules-commonjs-simple https://github.com/jamietre/babel-plugin-transform-es2015-mo... There is a better explanation with a partial solution.

seniorsassycat 10y ago
I don't think Babel is the cause, not in this case. Im using typescript in full es6 mode, module and target are both es6. Babel isn't even in my node_modules.
jamra 10y ago
Typescript doesn't need babel since the typescript compiler supports es6.
- dvcc 10y ago
  The 'let' should have made me re-think the problem.
deleted 10y ago
[deleted]

saosebastiao 10y ago

Stuff like this is the reason the Unix Philosophy of small "composable" tools doesn't work in this ecosystem. Because if you run your code through three different preprocessor steps, everything breaks and your source maps aren't even close to usable anymore, so you can't debug anymore. I've been campaigning for more of a monolithic design in the TS ecosystem. Not that the architecture of the TS compiler needs to be monolithic, but rather that TS users should have a blessed and supported stack for everything. We should be able to rely on TS components for linking/packaging, polyfills, optimization, conditional compilation, minification, source map packaging, asset prepackaging and loading, ES6+ standards compliance, etc. But since advocating for anything rhyming with -olith is heresy in the programming world, I'm not confident we'll get there.

seniorsassycat 10y ago
This isn't actually caused by piping data through many small tools, it's reproducible with solely webpack 2. https://gist.github.com/anonymous/ad044363f73b845cccb4e7f2259ac398 https://gist.github.com/anonymous/ad044363f73b845cccb4e7f225...

djmashko2 10y ago

This is a big benefit of Meteor's build system - it has several improvements that make debugging more straightforward than with Webpack and default Babel import compilation.