I've tried debugging typescript code in chrome which has enabled source maps in chrome. But no sourcemap files are loaded as can be seen in the network tab.
I'm using VS2012 and the latest web essentials package.
Any ideas what to do next?
If you want to debug inside VS 2012 you only need to set the breakpoint inside VS and use Internet Explorer when debugging.
from Say Hello to TypeScript
If you want to debug in Chrome with sourcemaps make sure that:
1.) they are enabled in Chrome (and you said you did that)
2.) they are generated by the IDE
You can enable their generation by using Web Essentials addon (check above article for details)
or
manually editing the project file's build step: https://stackoverflow.com/a/12730715/750216
Update:
It seems that at least in VS Express 2012 for Web sourcemaps are generated automatically by default - no settings needed.
You will not see sourcemap files in the network tab. If you go to the Sources tab you will see your typescript files in the list of Sources along the left. From there you can set your breakpoints.
Related
I'm using Aurelia JS skeleton for TS and JSPM from github as a started app and as I was playing with it and opened a second browser tab to compare data on different pages. But as I worked in one tab, what I did was duplicated on the other tab. So I opened an incognito tab and tried that. It did the same thing! Is there a way to configure it so that I can have a different view on each tab within the same app?
Browsersync does this, you can turn off things like mirroring when you surf to localhost:3001 (this is the default url for the Aurelia CLI, so it could be different in your setup)
when running the skeleton you can disable the browsersync feature you are seeing by simply running gulp serve instead of gulp watch from the terminal
I'm using GWT 2.7.0 with GXT 3.1.1 and IntelliJ 15.0.5 and Chrome 50. I debug my application using the Super Dev Mode (with a separate code server and bookmarklets) and up to now it's worked quite well.
However, for no apparent reason, today the Super Dev Mode has stopped working under Chrome (I can get it to work under IE 11). Everything works as before, but my *.java files are no longer visible in the Chrome Dev Tools.
I've been doing clean-and-rebuild (including cleaning gwt-unitCache), checking SO posts, reconfiguring SDM in IntelliJ, but so far nothing's helped.
Here's what I've managed to find out (inspired but this post):
Source maps are enabled
I can see source maps on gwtproject.org
In Chrome's Network tab I can see 2 requests for *.nocache.js (one to my server, the other to the code server). Neither of these requests has the X-SourceMap response header
There is NO request for gwtSourceMap.json
There is nothing interesting in the Super Dev Mode logs, this is the only reference to anything source-map-related:
Linking per-type JS with 5560 new types.
prelink JS size = 11286518
prelink sourcemap = 11286518 bytes and 260145 lines
postlink JS size = 10968640
postlink sourcemap = 10968640 bytes and 253152 lines
Source Maps Enabled
Compile of permutations succeeded
Compilation succeeded -- 34,546s
I have a separate module file for Super Dev Mode with just 1 permutation:
<set-property name="gxt.user.agent" value="chrome"/>
<set-property-fallback name="user.agent" value="safari"/>
I'm starting to run out of ideas (other than going through gwt sources), any help would be really appreciated.
I had a problem today with similar symptoms.
Eventually found that in chrome dev tool, i'd blacklisted an important gwt js file (project-0.js). I just didn't want to see it in tracebacks when i was debugging some native js stuff, but with that blacklisted, the sourcemaps weren't getting pulled in! Once I un-blacklisted it, I could once again load and debug gwt java in cdt.
I'd like to debug a GWT 2.7 based app using sourcemaps in Chrome. However, I don't want all sources to be included in the shipped WAR file. I managed to generate sourcemaps during Maven build using saveSource compiler setting.
Question now is, how can a "attach" sourcemaps to a running system from within the Browser.
I already have the sourcemap json file served by a local server and was also able to load sources from there by using context menu of the generated GWT js file:
This shows the java package hierarchy on the left - cool! However, break points in java files don't work and the source map entries disappear again on page reload, which means I would not be able to debug any initialization logic.
Any ideas?
Starting a new project, in my gwt module, I added the following lines of code:
<set-property name="compiler.useSourceMaps" value="true"/>
<set-configuration-property name="devModeRedirectEnabled" value="true"/>
<set-configuration-property name="CssResource.obfuscationPrefix" value="empty"/>
Starting the dev server in super dev mode after this allowed me to view my java code and also debug in all classes, including the entry point class. When a java breakpoint is set in the entry point class (I am using chrome 43.0.2357.81 m at this moment) I am able to refresh the page and the breakpoint is hit again.
Hope this helps!
I'm trying to get TypeScript source debugging working in Chrome, but I'm running into two specific and perhaps related problems.
The first is that the comment generated by the TypeScript/WebEssentials compiler that's supposed to identify the location of the source map file looks like this:
//sourceMappingUrl=MySourceFile.js.map
But Chrome won't read that file. It seems expect that the comment will look like this:
//# sourceMappingUrl=MySourceFile.js.map
If I manually change the comment to that, and refresh my page, then magically the references to all the .ts files show up as sources in the Chrome Developer Tools.
However, that leads to my second problem, as the files don't actually get loaded. The .ts source file that Chrome should be trying to download is http://localhost/MySourceFile.ts, but the one that it's actually trying to download is http://localhost/C:/source/web/MySourceFile.ts. That sort of makes sense, as the opening attributes of MySourceFile.js.map look like this:
{"version":3,"file":"tmp1523.tmp","sources":["C:/source/web/MySourceFile.ts"
But that obviously doesn't work with Chrome, as it interprets the source-map location to be entirely relative, and IIS (quite correctly) won't serve up any URL looking like http://localhost/C:/source/web/MySourceFile.ts.
So, with respect to these two problems, is it Chrome or the TypeScript source-map feature that's doing it wrong? And what's the recommended way of doing this?
I'm using Chrome 25.0.1323.1 dev-m, with TypeScript 0.8.1 and WebEssentials 1.8.5.
This is an issue with version 1.8.5 of Web Essentials (the version currently available from the Visual Studio Gallery). The latest nightly build (at time of writing http://madskristensen.net/custom/webessentials2012.vsix) fixes the problem and generates the map linkage correctly.
We are trying to distribute a basic HTML file with some links to a PDF document in a USB drive for advertising purposes. The idea is that an autorun opens up this HTML in the default browser. However, this might not be a good idea since it would look very amateur-ish and we will have to rely on the default browser's technology (which unfortunately has a good chance on being IE6/7!)
We've explored a few alternatives, but we can't find one that really fits what we are trying to achieve:
Mozilla Prism
Altough it seems like it's designed with offline web apps in mind, the executable creates files in the user's AppData directory and it's hard to configure the default paths. Also, Firefox doesn't have a default PDF viewer, so we will have to depend on the user's default PDF viewer (which might be Adobe Reader)
Mozilla Chromeless
Since Prism is inactive, the idea is still developing with Chromeless, which allows the developer to create the browser interface with basic HTML/JS/CSS. The main issue here is that somehow the build isn't loading HTML, all that's showing is a gray iframe. I'm not sure if it's just me, because there's nothing on the issues page.
Portable App
We could throw in the portable version of Firefox or Chrome and customize the XUL for Firefox or open Chrome in app mode.
Firefox's advantage is that it kind of supports relative paths (resource://), but it doesn't have a built-in PDF viewer. Chrome has a very good and lightweight PDF viewer and the built-in app mode is a very useful feature for us, but I can't find how to open a local path without the usual absolute path (file:///C:/) since we don't know what's the drive's letter.
Has anyone figure out how to handle this kind of issues? Thanks.
This has been asked three years ago, but it's unanswered, listed high in Google, and I stumbled over the exact same problem and can imagine that many others that seek to ship portable web apps that can be run locally and with a minimum of dependencies will encounter this issue, too.
The solution I am now going with is the node-webkit.
You can treat it like a portable version of chrome, however it excepts a relative path to your app's entry point, is about 40 MB smaller, and much more customizable than the --app mode of chrome (which isn't customizable at all if I remember correctly).
Github & Download:
https://github.com/rogerwang/node-webkit#downloads
An extensive guide:
http://thejackalofjavascript.com/getting-started-with-node-webkit-apps/
My usage suggestion for Windows:
First create an app package as explained in the guide linked above
For the node-wekit to load with your app, you need to start it like this:
nw.exe app.package
Where nw.exe is in the root of the zipped folder you downloaded and app.package is a zip file (can have any name) that contains your app data and package.json.
To do this silently, you can use a BAT file containing the (amended) call above and a VBS file containing something like this:
CreateObject("Wscript.Shell").Run "cmd /c launchNW.bat", 0, true
launchNW.bat being the name of your BAT file. Now run the VBS file; a window containing your web app should pop up without the command window appearing with it.
Finish reading the linked guide to learn more about customization options to do things like hiding the browser UI etc.