Allow dirname of source path referenced by sourcemap to be customized

[mojavelinux]

By default, the dirname of the source paths referenced by the sourcemap mirrors the src glob. For example, if the source CSS file is css/site.css, then the source paths for each @import when sourcemaps are enabled become css/base.css, etc. However, it's not clear what "css" refers to here, especially if the output folder for the CSS is already "css". Then, you get "css/css/base.css" in the developer tools.

It would be ideal if the base directory were to be named after the file in which the imports were resolved. For example, the sourcemap would instead be site.css-src/base.css.

The line of code I'm looking to be able to customize is this one:

return path.join(path.dirname(file.relative), source)

I'm looking for something like:

return path.join(file.basename + '-src', source)

or even:

return path.join(file.basename + '-' + source)

I'm open to any configuration that would give me control over that line, even if it's a callback function.

[stof]

gulp.src already allows to customise that thanks to its base option. In my own project, I'm using gulp.src('assets/css/*.css', { 'base': '.' }), which makes paths be relative to the root of the project rather than to the static prefix of the glob pattern.

The behavior of gulp-postcss is to respect what gulp manages as file.relative, so there is nothing to change in it IMO.

[w0rm]

Yeah, I think setting the base option for the glob pattern should work!

[mojavelinux]

I'm afraid you've misunderstood my point. I assert that the behavior of postcss is still incorrect. I will elaborate.

Let's assume I have the following structure:

src/
  css/
    site.css
    base.css
    body.css

And site.css looks like this:

@import "base.css";
@import "body.css";

Now assume I compile the CSS files as follows:

vfs
  .src('css/site.css', { base: 'src', cwd: 'src', sourcemaps: true })
  .pipe(postcss(postcssPlugins)),

The sourcemap file for css/site.css (css/site.css.map) will contain:

"sources":["css/base.css","css/body.css"]

That's suggesting that the files are located at css/css/base.css and css/css/body.css, respectively. That is incorrect. They should be "base.css" and "body.css" (as they are in the source).

Unless I'm mistaken, there's no way to control this using the base option. By manipulating base, the site.css file just ends up in the wrong directly. Please enlighten me if there is a way.

You can see an example of this scenario in the following project. https://github.com/asciidoctor/asciidoctor-docs-ui

[stof]

@mojavelinux if you pass a relative pass to base, it is relative to cwd. So that's your own config being wrong. Either use absolute paths, or use the right relative paths.

[stof]

Btw, I don't understand your point. If you tell that the base is src, css/base.css is not wrong at all. that's indeed the relative path of the base.css file compared to the base.

[mojavelinux]

gulp.src already allows to customise that thanks to its base option. In my own project, I'm using gulp.src('assets/css/*.css', { 'base': '.' }), which makes paths be relative to the root of the project rather than to the static prefix of the glob pattern.

I don't understand how this helps at all. If I do this, then I get 'src/css/site.css' in my output folder.

if you pass a relative pass to base, it is relative to cwd. So that's your own config being wrong. Either use absolute paths, or use the right relative paths.

What you are suggesting simply doesn't work. If I don't set base and cwd as I do, either it cannot find the files or it creates the wrong paths in the output folder.

[mojavelinux]

css/base.css is not wrong at all. that's indeed the relative path of the base.css file compared to the base.

No, because the sourcemap is providing relative paths to the aggregate file. So for it to reference 'css/base.css' is incorrect. The relative path from site.css is base.css, not css/base.css.

[mojavelinux]

My point is not that site.css is not being processed. (It is being processed). That is not the problem. The problem is that the path in the sourcemap is wrong.

[mojavelinux]

No matter what I set base to, the path in the sourcemap is still wrong. The path should honor the path of the import. That is what I'm arguing for.

[mojavelinux]

Btw, if I set base: '.', and use 'src/css/site.css' in the glob, here's what I get in my output folder:

src/
  css/
    site.css

I don't want that. I want this:

css/
  site.css

The point here is not to change the structure vinyl-fs is creating. The structure I have is the structure I want. I'm focused on the contents of the sourcemap file, specifically the paths of the imported files.

[stof]

@mojavelinux why would you want to see base.css but css/site.css ? If you want to see only paths relative to the css/ folder and not the src/ folder, it means that your base should not be the src/ folder but the css folder.

All paths in a sourcemap are meant to be relative to the same base folder. They are not relative to the place using them (as the sourcemap does not have a concept of where the base.css file is used from)

[mojavelinux]

All paths in a sourcemap are meant to be relative to the same base folder.

That's not how the browser sees it. When I load the page, Firefox reports the sourcemap file as:

css/css/base.css

You can think that the sourcemap file is relative to the base, but the browser doesn't.

[mojavelinux]

as the sourcemap does not have a concept of where the base.css file is used from

That reinforces my original point that there needs to be a way to configure this (independent of the base option, which is controlling a different aspect of processing).

[stof]

@mojavelinux well, if you dump your sourcemaps inside the css/ folder in your output, then your basis should also be the css/ folder, not the src/ folder. But that's not only about base.css. You will have the same issue for site.css (except you have no rules in this file directly to see the issue). You should configure a base folder consistent with the place where you dump the sourcemap (or use more advanced features of sourcemaps to configure the sourcemap root, but I don't how whether/how gulp exposes these features when dumping sourcemaps as I never tried to use them)