Mini-css-extract-plugin: Access Entrypoint Chunk Name At Runtime

[philipp-spiess]

We're using mini-css-extract-plugin to generate a CSS entry point that we're dynamically appending to the contents of an <iframe> at runtime.

To enable long-term-caching, we'd love to add a content hash to the resulting .css file. This works great and is documented here.

However, since we're manually loading the CSS at runtime, we'll need a way to access the resulting chunk filename there as well. I can only seem to find solutions which will emit the mapping as an external file. Solutions like the file-loader will allow access to the resulting chunk name at runtime - something like this would be ideal for our use case.

What's the best-practice solution to dynamically load the generated CSS file in our use case?

[montogeek]

A manifest file could be useful for your case: https://github.com/danethurber/webpack-manifest-plugin

[philipp-spiess]

@montogeek The manifest file would emit a _new_ file which would need to be loaded at runtime and which would not be allowed to have long-term-caching enabled. And there's of course also an additional performance penalty for loading and parsing another file.

I was wondering if there's a solution to inline the contents of this file into the main entry point to have it available in the webpack runtime. Ideally, we can make all but one file (the entry point) long term cacheable which will make the usage of our product a lot easier.

[johnelliott]

@montogeek we use the manifest file in our app when the server starts, we use node's fs.readFileSync to suck up the JSON and pass the mapping down into the express app to let react render pages with the right css paths on disk.

This is the pattern I hope we can get away from. It is a work-around because we haven't figured out how to properly use webpack to reference our stylesheets.

Ideally we'd import the stylesheet source files in the server code and the import would be the path name that we just put into

edit: I don't think our case is exactly related to what you're trying to do.

[michael-ciniawsky]

Could someone try to provide a basic code example of how this should ideally look like (if possible to achieve) ? e.g

import('./entry.css').then(({ url }) => console.log(url)) // chunk.32587i55.css (?)

But I don't think it is possible to do it that way, I need to think about it :)

However, since we're manually loading the CSS at runtime

Please provide code and elaborate futher on how this looks like in particular, hard to tell atm :)

[philipp-spiess]

@michael-ciniawsky Sorry for the late reply. I'm not sure which API makes sense here, perhaps you could implement this with a custom loader, e.g.:

import('css-filename!./entry.css').then(url => console.log(url)) // chunk.32587i55.css (?)

Please provide code and elaborate futher on how this looks like in particular, hard to tell atm :)

Ideally we could build something like this:

import url from "css-filename!./entry.css";

// We need to load the CSS file into a different realm
const iframeDocument = iframe.contentWindow.document;

const head = document.head;
const link = document.createElement("link");
link.type = "text/css";
link.rel = "stylesheet";
link.href = fileName;

iframeDocument.head.appendChild(link);

Right now we achieve this by using a hardcoded filename so that we can rely on it being custom.css all of the time but we'd like to include content hash in the filename to improve our caching solution.

[Quirksmode]

@philipp-spiess Did you manage to solve this?

[philipp-spiess]

@Quirksmode We're solving the usecase via https://github.com/webpack-contrib/mini-css-extract-plugin/pull/459 now :-)

[sophiebits]

It looks as though it's possible to solve this using a variant of what https://github.com/webpack-contrib/worker-loader does – running the entire webpack compiler as a "child" of the main one to produce a bundle that you can reference. I think it's likely possible to make a general purpose version of this but haven't had the time.

[alexander-akait]

You can achieve the insert option in v1.1.0, rely on filename is not good idea, but feel free to feedback, maybe I a missing some edge cases