Using SuperDevMode with code splitting

[Luis Fernando Planella Gonzalez]

Hi.

I'm recently attempting to use SuperDevMode, but our project is quite large, and the generated compiled .js has ~12MB.

Chrome struggles (and hangs) when attempting to download source maps, making the whole debugging unpractical.

Without SuperDevMode, we use code splitting, and the fragments are much more manageable.

But SuperDevMode always compiles the application to a single .js file.

Is it possible to use code splitting with SuperDevMode?

[Luis Fernando Planella Gonzalez]

Well, after patching CompilerOptionsImpl in gwt-codeserver.jar to return true in isRunAsyncEnabled(), the code server started splitting the code, but source maps were only generated for the initial fragment.

I don't know the internals, but shouldn't be terribly hard to have the source maps for each split point, right? Or isn't it at all supported by the compiler?

Compiling using "-saveSource -saveSourceOutput <dir>" together with <set-property name="compiler.useSourceMaps" value="true" /> and <set-configuration-property name="includeSourceMapUrl" value="true" /> correctly saves all sources in the output dir and sets the source map comments on each script...

Also, the CompilerOptionsImpl has this:

  @Override

  public boolean shouldSaveSource() {

    return false; // handling this a different way

  }

This "different way" is explicitly not handling the runAsync case.

Is there a strong reason for this?

Thanks in advance.

[Thomas Broyer]

On Friday, February 14, 2014 8:50:22 PM UTC+1, Luis Fernando Planella Gonzalez wrote:

Well, after patching CompilerOptionsImpl in gwt-codeserver.jar to return true in isRunAsyncEnabled(), the code server started splitting the code, but source maps were only generated for the initial fragment.

I don't know the internals, but shouldn't be terribly hard to have the source maps for each split point, right? Or isn't it at all supported by the compiler?

Compiling using "-saveSource -saveSourceOutput <dir>" together with <set-property name="compiler.useSourceMaps" value="true" /> and <set-configuration-property name="includeSourceMapUrl" value="true" /> correctly saves all sources in the output dir and sets the source map comments on each script...

Also, the CompilerOptionsImpl has this:

  @Override

  public boolean shouldSaveSource() {

    return false; // handling this a different way

  }

This "different way" is explicitly not handling the runAsync case.

Is there a strong reason for this?

SuperDevMode loads the source code right form its classpath (the same way as when it compiles it) when sending it to the browser (see SourceHandler and ModuleState).

That said, copying the sources would solve https://code.google.com/p/google-web-toolkit/issues/detail?id=7615 (but saveSource has only been added recently, and I suspect SuperDevMode just hasn't caught up yet)

 

[Luis Fernando Planella Gonzalez]

I've reported https://code.google.com/p/google-web-toolkit/issues/detail?id=8581 regarding this.
It is very important for large projects to work with SuperDevMode.
So, if anyone has the same problem, please, start the issue.
Best regards, Luis

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/dFyODLo7QMo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

[Klemens Schrage]

Maybe there are technical reasons for this since trying to use SourceMaps with CodeSplitting in a production environment gave me debugging problems (see https://groups.google.com/forum/#!topic/google-web-toolkit/kUpx5pOkqJs).

[Luis Fernando Planella Gonzalez]

Well, I hope this will be sorted out, because debugging on a monolithic
code of hundreds of thousands lines of code simply doesn't work - the
browser hangs as expected.
There's the following statement on
http://www.gwtproject.org/articles/superdevmode.html : "Currently, Super
Dev Mode doesn't work on some very large GWT apps where classic Dev Mode
works".
This is probably because of the generated JS code size, but I'm sure
this will be worked out. Otherwise, GWT will die in the short-mid term,
because browser plugin based debugging is mostly dead (already in FF,
soon in Chrome).

Luis Fernando Planella Gonzalez

> <https://groups.google.com/forum/#%21topic/google-web-toolkit/kUpx5pOkqJs>).