Webpack 2, RC 4 (opens in new tab)

(github.com)

64 pointsjfmercer9y ago20 comments

20 comments

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.

johnny_reilly9y 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...

And in the official samples (WebPack 1): https://github.com/Microsoft/TypeScriptSamples/tree/master/r...

seniorsassycat9y 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/ad044363f73b845cccb4e7f225...

Specifically, look at lines 25 and 28 of lib-main.js

1 more reply

dvcc9y 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-mo...

There is a better explanation with a partial solution.

jamra9y ago

Typescript doesn't need babel since the typescript compiler supports es6.

1 more reply

seniorsassycat9y 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.

saosebastiao9y 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.

seniorsassycat9y 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/ad044363f73b845cccb4e7f225...

djmashko29y 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.

jfmercerOP9y ago

According to sokra, this ought to be the final rc. From the release notes: "This is probably the last RC. We released it as final test. If no critial bugs are discovered, we release 2.2.0 in < 10 days."

k__9y ago

I tried the dynamic import/require once and it was really nice.

I could just write a normal SPA and require some stuff in every route, so the client only downloads the code that is used for the current page and things worked fine without extras needed.

simplify9y ago

That almost sounds like server-side rendering :)

patates9y ago

But SSR means you send everything around the content again and again.

1 more reply

VMG9y ago

Aaaand github unicorns..

vanni9y ago

"We are currently experiencing major service outages."

https://twitter.com/githubstatus/status/819940738452615168

Hilarious replies on Twitter.

AznHisoka9y ago

Looks like there is some connectivity issues in OVH as well.. not sure if related?

j / k navigate · click thread line to collapse

20 comments

seniorsassycat9y ago

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.

johnny_reilly9y 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...

And in the official samples (WebPack 1): https://github.com/Microsoft/TypeScriptSamples/tree/master/r...

seniorsassycat9y 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/ad044363f73b845cccb4e7f225...

Specifically, look at lines 25 and 28 of lib-main.js

1 more reply

dvcc9y 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-mo...

There is a better explanation with a partial solution.

jamra9y ago

Typescript doesn't need babel since the typescript compiler supports es6.

1 more reply

seniorsassycat9y 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.

saosebastiao9y ago

But since advocating for anything rhyming with -olith is heresy in the programming world, I'm not confident we'll get there.

seniorsassycat9y 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/ad044363f73b845cccb4e7f225...

djmashko29y 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.

jfmercerOP9y ago

k__9y ago

I tried the dynamic import/require once and it was really nice.

I could just write a normal SPA and require some stuff in every route, so the client only downloads the code that is used for the current page and things worked fine without extras needed.

simplify9y ago

That almost sounds like server-side rendering :)

patates9y ago

But SSR means you send everything around the content again and again.

1 more reply

VMG9y ago

Aaaand github unicorns..

vanni9y ago

"We are currently experiencing major service outages."

https://twitter.com/githubstatus/status/819940738452615168

Hilarious replies on Twitter.

AznHisoka9y ago

Looks like there is some connectivity issues in OVH as well.. not sure if related?

j / k navigate · click thread line to collapse