[path] placeholder

[glen-84]

[name] returns the name of the chunk that imports the CSS file, from what I understand. I need to get the name/path of the imported CSS file.

The file-loader has a [path] placeholder that returns The path of the resource relative to the context. Is it possible to add something similar to this plugin?

(either that, or add this information to the filename function)

[sokra]

This doesn't make sense. What's you use case for this?

[glen-84]

If I do this:

scripts/main.ts

import "../styles/main.scss";

... the CSS file is saved to scripts/main-57a9c47e715c86dc8071.css. However, I obviously want CSS to be saved to a location based on the path it was imported from (/styles in this case).

This is similar to #67, and if that function has enough data in the arguments provided, it might be a viable alternative.

Either that, or CSS entrypoints 😛 (related)

PS. I'm new to webpack, so if I'm missing something obvious, please excuse me.

[glen-84]

@sokra,

I should have mentioned, I use paths for my chunk names, and not simple names like "page1".

By using:

entry: {
    "scripts/main": "./scripts/main.ts",
    // more
}

My JavaScript files are written to subdirectories of the output path (when using [name] in the filename template).

If a JS file references a CSS file, and the mini-css-extract-plugin filename template is set to [name]-[contenthash].css, the CSS file is written to scripts/main-{hash}.css. In other words, [name] refers to the chunk name of the entry file.

However, I (and I'm sure others) need to be able to write the CSS to a path based on its actual path on disk (in the src). Either in the form of additional placeholders (this issue), or via a filename function (#67) that is called with enough context to extract that data.

The data seems to be available under CssModule.issuer.id (or .resource), but I don't really know much about the internals of webpack.

My use case is a multi-page website, where the server-rendered templates (PHP/Twig) should be able to reference an asset using its source path, which then returns the relevant path(s) in the output directory.

For example, if the template asks for /scripts/main.js, /scripts/main-{hash}.js will be returned (or multiple assets in some cases). If the template asks for /styles/example.css, this won't be found because the file is actually under /scripts.

Hopefully this makes some sense. It's really about maintaining the directory structure of CSS files, instead of putting them together with the JavaScript.

Edit: CSS modules as entry points would probably be a better/cleaner solution, but it might be a long time before that is available and stable.

[michael-ciniawsky]

#92 (comment)

[glen-84]

@michael-ciniawsky,

I answered that as best I could, with two detailed explanations.

What is the status of the CSS modules support that you were working on?

[michael-ciniawsky]

Yes I understand, but for a extracted CSS chunk/file which modules issuer path should we use for a potential [path] placeholder (by default) to substitute, as we affectively making a new chunk that doesn't exists on disk (yet)? Using options.filename to specify a subdir is not straightforward agreed, but even with a new option it would still need to be manually be specified

Asset path generation is roughly working in the following way

// compiler.options.output.path === config.output.path (webpack.config.js)
const name = options.filename || chunk.name
const asset = compiler.options.output.path + name

compilation.assets[asset] = new RawSource(css)

[michael-ciniawsky]

What is the status of the CSS modules support that you were working on?

Well the PR is very rough atm, all the postcss plugins used there need to be extracted and I need to rebase. It work(ed) for the usual case but webpack has support for a lot of different setups so it might still be a long way to get it 'right' :)

[glen-84]

I think I understand what you're saying. If a JS file references a/b/c.css and x/y/z.css, and those two CSS files are bundled together, then you don't know if [path] should be a/b or x/y.

I think what I actually need(ed) is CSS entrypoints, which (AFAIK), don't really work properly at this stage. If I understand correctly, first-class support for CSS modules would make this a lot easier.

Something like this would also be cool. (HTML entry files)

Well the PR is very rough atm, all the postcss plugins used there need to be extracted and I need to rebase. It work(ed) for the usual case but webpack has support for a lot of different setups so it might still be a long way to get it 'right' :)

Thanks for the update. It would be nice if this page could be updated to remove the [IN PROGRESS] so that users could continue to vote on that feature.

[michael-ciniawsky]

I think I understand what you're saying. If a JS file references a/b/c.css and x/y/z.css, and those two CSS files are bundled together, then you don't know if [path] should be a/b or x/y.

Exactly, e.g the file-loader can provide a [path] placeholder since it works on a per module basis, where the module.issuer && module.request is known and unambiguous. On the other hand the mini-css-extract-plugin operates after all modules are loaded and on a per chunk basis, which is an abstract data type for a 'group of modules' in the graph. It can only be 'named' and needs a known unambiguous destination to output it to (e.g via config). Having to have to add the subdir as the name is weird as mentioned. I remember struggling with this aswelll when I first used the extract-text-plugin back in the days :). webpack is entirely JS focused at the moment, which leads to all of this workarounds necessary to get CSS 'working' e.g something in the vein of

webpack.config.js

const config = {
   output: {
      path: {
        '.js': 'dist',
        '.css': 'dist/styles'
      }
   }
}

would be better and possible, if CSS is a first class citizen 😛

Something like this would also be cool. (HTML entry files)

😆 I wrote my own bundler for learning proposes and it is based on exactly that idea, it is soooo much easier if you use an HTML File as the entrypoint and opens the door for MPA (Multi-Page Applications)* nearly naturally, while SPA (webpack's bread and butter (many JS Entries + index.html)) continue to work as before with the only difference that config.entry becomes /${app}/index.html:)

*

|–
|– src
||
||– index.html
||
||- a (SPA 1)
|||– index.html
|||– index.css
|||– index.js
|
||- b (SPA 2)
|||– index.html
|||– index.css
|||– index.js
|
||- c (SPA 3)
|||– index.html
|||– index.css
|||– index.js
|
| ...
|
|– dist
||- index.html
||– a
|||– ...
||– b
|||– ...
||– c
|||– ...
|
|- webpack.config.js
|- package.json

It also partially implemented already in the PR I made to webpack for HTML (not sure if I pushed the lateest code there, but I used it already (locally) 😛)

• Dependency Type (https://github.com/webpack/webpack/pull/6447/files#diff-d20397fdcf123bea36562d0993e66f86R18)
• HTML Plugin (https://github.com/webpack/webpack/blob/bb446b193c27e0af164b06419afe6fc0256a23ca/lib/html/HTMLParser.js#L23-L48)

The problem as with CSS is that again with all possible configs webpack supports atm (which are specific to having JS as an entrypoint), this requires more work to function properly in webpack

Thanks for the update. It would be nice if this page could be updated to remove the [IN PROGRESS] so that users could continue to vote on that feature.

😯 Ohh I don't now what's the status of the voting page to be honest, but it is still is kind of in progress as we continued to work on some CSS related stuff. I also may continue these PR's in the near future :)