Visual Studio debugger breakes from adding When to WebPack bundle.

[henrify]

If I create a CommonJS compatible bundle using WebPack and include 'When' library in the bundle, then debugging in Visual Studio (2013 and 2015) brakes:

• Brakepoints are not hit
• Warning 'The breakpoint will not currently be hit. No symbols have been loaded for this document' is displayed next to breakpoints.

Additional info:

• If I don't include When to the bundle, but keep everything else exactly same, then debugger works fine.
• If I create the bundle using Browserify instead of WebPack, then debugger works fine.
• If I include another library of comparable size instead of 'When', then debugger works fine.

Please find attached Visual Studio solution for repro.

After running commands 'npm install' and 'webpack', you can debug this just fine in Visual Studio. If you remove the comments from the six lines that include 'When' to the bundle and run 'webpack' again, then Visual Studio debugging brakes.

I'm not sure if this is WebPack or When issue or bit of both, so crossposting.

WebpackWhenSourcemapTest.zip

[briancavalier]

Wow, I have no idea :) I've not heard of any other issues using when with webpack.

If I create the bundle using Browserify instead of WebPack, then debugger works fine.

That seems fairly compelling that it's something out of when's control. Although, I guess there could be some perfectly legal structure in when that causes webpack to generate code that confuses VS?

I don't use VS, and don't really have access to it (running on OS X), so I'm not sure how to help. Is there a prebuilt VS VM I could download perhaps?

[henrify]

I've not heard of any other issues using when with webpack.

But have you heard any reports of the inverse: people who definitely use latest When with latest Webpack?

That seems fairly compelling that it's something out of when's control.

On the other hand WebPack with any other library than when works, so the same argument could be made equally well from WebPack's side...

As for testing:

• There is no prebuild VM with Visual Studio, but VS2015 Community Edition is free and simple double click installer.
• You probably should anyway start testing a bit with Windows, e.g. as I just reported the build on Windows seems to have gotten completely broken since 3.7.3.
• You can Download Windows 7 or 8 virtual machine here: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/windows/
• And you can get free Visual Studio here: https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx

[henrify]

Just to report one failed attempt. The sourcemaps contain fairly funky looking vertx stuff (file://ignored) and your change log reports previous issue with Wepack and Vert.x, so I did custom build of 3.7.3 that removed vertx require entirely, but that did not help.

[briancavalier]

But have you heard any reports of the inverse: people who definitely use latest When with latest Webpack?

I haven't, but that's the kind of thing you tend to hear about when it doesn't work (like now) rather than when it does.

I'll try soon with the latest webpack on OS X. Thanks for the links to the VMs and VS CE. I'm not sure when I'll be able to get around to testing on windows, though.

Sorry about the backticks. Thanks for pointing that out. Those were added recently in #476, and I admit I don't always do a good job of thinking about windows-specific issues.

Tagging @dominykas to see if he has ideas for making those npm scripts windows compatible.

[dominykas]

I've never used vert.x and I don't have a Windows machine... sorry...

@henrify would you be able to reproduce your issues on AppVeyor with a PR?

[henrify]

@briancavalier Ok, i guess we'll have to leave it as inconclusive whether webpack+when works for others or not. There are also lot of other factors that may cause the problem to be more specific, e.g. as you saw in screenshots this was with typescript (ts-loader).

After the previous post I installed new Windows 8.1 VM and Visual Studio, and the problem repros 100% in virgin environment. I also tried with all different webpack 'devtool's (like cheap-sourcemap etc.) and evetything was equally broken.

I've wasted full work day on this now and cannot spend any more time, and browserify works for now, so maybe we can just leave the issue open waiting for time when you'll have opportunity to install the Windows VM?

[henrify]

@dominykas I don't think that CI server is realistic alternative. You need to have access to actual OS before you can efficiently troubleshoot and, pun intended, debug issues like this.

Secondly, the vert.x mention was negative confirmation: I tried eliminating vert.x and it did not solve the problem. Just mentioned so that others don't waste time doing that investigation.

Thirdly, about the build issue, using $() for substitution instead of backticks is portable across many UNIX shells and Windows PowerShell. It would still leave building from Windows command prompt broken, but life is sometimes imperfect.

[briancavalier]

Secondly, the vert.x mention was negative confirmation

Good info, thanks.

leave the issue open waiting for time when you'll have opportunity to install the Windows VM?

Yes, definitely. I want to try latest webpack on OS X asap, and then I'll try the VMs when I can make a little more time.

using $() for substitution instead of backticks is portable across many UNIX shells and Windows PowerShell

Excellent suggestion, thanks. I can probably test that relatively soon.

[briancavalier]

Ok, I built a small test app with a single JS file that required and used when, and an index.html file. I built it with both webpack 1.13.0 and 2.1.0-beta.6. It generates source maps using webpack's --devtool source-map option.

The build worked in each case. Breakpoints seem to work in chrome (didn't test other browsers). Feel free to try it out--it's currently set to use webpack 2.1.0-beta.6, but you can change package.json or manually install 1.13.0 to try that version.

So, at least as far as when and webpack working together at a basic level, that doesn't show any obvious conflicts.

I haven't had a chance to try VMs yet.

[henrify]

@briancavalier yes as the subject line says, the problem is only with Visual Studio (and likely other IDEs), sorry that I wasn't more clear that it does not occur with browsers.

So.. browsers load the source code from the sourcemap's "sourcesContent" property, while IDE's use the paths defined in "sources" property to establish linkage between what is running in browser and what files are available in the IDE. It is the latter that When (and only When, and only with WebPack) for some reason brakes.

[dominykas]

@henrify does the problem persist if you require('when/when'), rather than require('when')? The sourcemap that's bundled in the package links to the GitHub repo - I don't recall the details, but either browserify, or Uglify did not want to use relative paths for that (or was it some other issues related to base path of the sources?... or was it maybe for CDN support when embedding the file directly...) So in theory, if you were to require the "source" file directly, your local WebPack would build a fresh source map from scratch, rather than use the bundled ones.

[henrify]

@dominykas I'm using TypeScript so I cannot easily require('when/when') without massaging ts.d, which might then confound the results, but seeing that package.json defines when.js as the 'main', requiring 'when' or 'when/when' should be functionally equivalent anyway.

And Webpack already builds the sourcemap from scratch based on the sources, and the built sourcemap (which is included also in the attached zip) has correct paths. The pre-build sourcemap in 'dist' folder is not used at all.

I assume that the issues that you are recalling are related to some user having difficulties getting the pre-build sourcemaps from dist folder working?

[dominykas]

I assume that the issues that you are recalling are related to some user having difficulties getting the pre-build sourcemaps from dist folder working?

The issues I [don't] recall in the dist folder are because I added the sourcemaps there. The primary use case I was playing with in there was for inclusion via <script src>, if I recall correctly (I know, I know, ancient JS).

So WebPack ignores the browser field in the package.json? I did not know that. My theory is incorrect then :) Oh well. Just an idea I thought worth following up.