Skip to content

0.3, too many source map configs removed? #159

Closed
johanneswuerbach opened this Issue Feb 17, 2014 · 8 comments

4 participants

@johanneswuerbach

I'm trying to update an app using grunt-usemin from 0.2 to 0.3, but I've a hard time to get sourcemaps to work again.

usemin is invoking uglify by default with the following options:

{ files: 
  [ { dest: 'dist/scripts/components.js',
      src: [ '.tmp/concat/scripts/components.js' ] },
    { dest: 'dist/scripts/plugins.js',
      src: [ '.tmp/concat/scripts/plugins.js' ] },
    { dest: 'dist/scripts/templates.js',
      src: [ '.tmp/concat/scripts/templates.js' ] },
    { dest: 'dist/scripts/main.js',
      src: [ '.tmp/concat/scripts/main.js' ] } ] } }

The config I'm using with 0.2 to generate source maps is:

uglify: {
  options: {
    sourceMap: function(dest) {
      return dest.replace(".js", ".map.json");
    },
    sourceMappingURL: function(dest) {
      return dest.replace("dist/scripts/", "").replace(".js", ".map.json");
    },
    sourceMapPrefix: 3
  }
}

With 0.3 it is only possible to change the name of the source map, but the possibility to change the path of the referenced sources was removed. The automatic generation is generating .tmp/concat/scripts/ for me, which is not a public url and should not be published.

What do you think is the best way to handle the case when the automatic generation is not working in a specific app?

@jmeas
grunt member
jmeas commented Feb 17, 2014

To get this same set up working, you'll need to:

  1. Make sure the source files, or copies of them, are accessible via your web server
  2. Use those source files as the src of uglify.

This is typically done by copying the source files over to the web server before uglifying them, then setting the copies as src.

If this set up originally produced a working source map, I imagine it probably copied the source files over in another step, so it shouldn't be any more steps for you – just a slightly different configuration.

Let me know if that helps.

@jmeas jmeas closed this Feb 17, 2014
@johanneswuerbach

Yes, copying the files before would be an option, but this means usemin would not work out-of-the-box anymore. Also I think not providing a way to overwrite an automatically generated default decreases the usability a bit.

@jmeas
grunt member
jmeas commented Feb 18, 2014

@johanneswuerbach, what's your usemin configuration?

Also I think not providing a way to overwrite an automatically generated default decreases the usability a bit.

//cc @mzgoddard. I tend to agree with this; it is a bit weird to first copy the source files, then use them as the src. What do you think?

@johanneswuerbach

I use the default configuration from the yeoman generator-ember. (An index.html in app/, which is moved to dist/index.html during build)

usemin is compiling and concatenating all files into .tmp/scripts/concat and then uglifys the result into dist/scripts/

Here the official docs: https://github.com/yeoman/grunt-usemin#transformation-flow

Today this generates source maps referencing .tmp/scripts/concat. With 0.2 I can overwrite this path and copy the original files into dist/scripts after the uglify and filerev tasks finished. This ensures also that the original files are not renamed with by filerev.

@jmeas
grunt member
jmeas commented Feb 18, 2014

Most generators, generator-ember included, don't come with source maps set up out-of-the-box. If you really want to use 0.3.0+ with source maps, and without changing the configuration too much, then it would probably be best to write a new generator for it. If you don't feel like doing that, I'd suggest sticking with < 0.3.0 for a bit longer.

My reluctance to reintroduce the option is because of the fact that pretty soon (> 0.3.0) the default behavior of source maps across the grunt-contrib suite will be embedding the content of your source files directly into the map, so their original locations won't matter at all. I can't think of a reason why someone would choose to link to the maps instead of embedding, so at that point this will be a non-issue. @mzgoddard and I are hard at work to get this implemented, so hopefully in a few weeks there will be something to show.

The new options for source maps can be read about here. If you have any suggestions for improving them I'd appreciate the feedback.

@johanneswuerbach

Embedding the source files into the map works for me and removes the copy task. Thanks for the feedback :-)

@mzgoddard

Glad embedding worked. Embedding will help in a bunch of edge cases that would otherwise be hard or annoying. I'm guessing sourceMapPrefix was the old option that helped and is a convenience hack that we should avoid adding back.

The thing that would really help is having source map support in the whole build process. That way grunt-contrib-uglify doesn't need hack options to help it track down files from the first task transforming anything. For the process created by generator-ember and other generators having support in grunt-contrib-concat will be a big step for that. This problem should get better soon since source map support should land in grunt-contrib-concat soon!

@tkellen
grunt member
tkellen commented Feb 18, 2014

<3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.