Sourcemap basepath could apply to paths written in .map file

[iamkevinv]

This is related to:
#1050 - Allow creating a source map
#1543 - Sourcemap basepath option

There's a real need to support the ability to trim some of the prefixing folders in the paths written into the sourcemap file. I expected the source-map-basepath to do this but on inspection it only alters the path written in the compressed css.

I have a path required for the compiler to see in order to find files for reading and writing, but the resultant source map shouldn't reference it, as the web server treats the first subdirectory as the root to serve from.

<projectdir>/
...
    WebContent/
        brand/
            css/
                brand.css
                brand.css.map
            less/
                brand.less
...

• The less compiling task via grunt is run from the base.
• Files I reference for the src and dest are 'WebContent/brand/css/brand.less' and 'WebContent/brand/css/brand.css' with 'WebContent/brand/css/brand.css.map' as source map.
• Due to my webserver effectively renaming 'WebContent/' to something else, I need to strip that out of the paths written in the *.map file's "sources":["...","...",...] array. I would then set the root path option to get a new prefix.
• The paths there seem to be whatever the full paths were to the sources.
• The base path option already existing could be set to 'WebContent/' to have it removed from the output in the /*# sourceMappingURL= */ but currently this doesn't happen to anything written in the *.map file's "sources":["...","...",...] array. Seems like that option should apply there too since we're defining a new base, but i'll leave that for thinking about as solution (a).
• Otherwise, there could be a new option to specify a numeric depth value of how many levels down to strip from the path prefix, like '1' or '2' deep. My best way to describe that (b) solution option is someone else's simple implementation for it:

For JS, UglifyJS2 provides for:

-p, --prefix
Skip prefix for original filenames that appear in source maps. For example -p 3 will drop 3 directories from file names and ensure they are relative paths. You can also specify -p relative, which will make UglifyJS figure out itself the relative paths between original sources, the source map and the output file.
[string]

I actually use: grunt-contrib-uglify in grunt which wraps this as:

SourceMapPrefix:
Type: Number
Default: undefined
The number of directories to drop from the path prefix when declaring files in the source map.

The result of using that would mean i could pass in 'WebContent/brand/css/brand.less' as a source but specify SourceMapPrefix of 1 and have the sources array in the sourcemap file write out ''brand/css/brand.less'. In combination with a set sourceMapRootpath of '/new/' i could get "/new/brand/css/brand.less" written in the sourcemap sources array items.
Then everything would work.

Personally i like option (a) where specifying a basePath string would apply it to the source paths too as it does to the source map url. Perhaps a toggle to enable that?

Sorry for the long winded post.

[lukeapage]

Hi,

What does appear in the sources section ? is it "WebContent/brand/css/brand.less" or is it "FULL_PATH/WebContent/brand/css/brand.less" ?

We do use the basepath option for sources and we do not have just a generic number of directories because we are better than that - directories are more specific and stop confusion because we import files over sub directories.

use the inline options if you like - then you don't need to worry what paths you get.

[iamkevinv]

Hi @lukeapage - thanks for your info so far...
Yes, the "WebContent/brand/css/brand.less" is the pattern getting output, even though my sourceMapBasepath is being set as "WebContent/".
I'm very glad that 'we are better than that'. Was just trying to give out some options based on other things i worked with.
If the sourceMapBasepath is meant to strip out the WebContent/ as i suspected it would, then yeah, it's not working.
However that said - i'm not sure if it's not working because of grunt-contrib-less or because of the original less compiler. Could you suggest a test you'd prefer me to run rather than me cooking a few of my own?
Cheers.

[lukeapage]

are all the path seperators consistent? We did fix a bug this release where they weren't being 100% normalised.

I know people are using grunt-contrib-less and the base path option and its working for them, so I just need a full example of where its not. if you can put a cut down example somewhere it would be very useful.

[lukeapage]

closing from lack of response