Implement manifest.json output

[NullVoxPopuli]

Resolves: #993

limber/frontend/dist on  asset-map-shadow-dom [$✘!?] 
❯ cat manifest.json | jq
{
  "assets/limber.js": [
    "assets/chunk.81ac289ee023d7347c6f.js",
    "assets/chunk.e1d54021e4e0e5b57234.js"
  ],
  "assets/vendor.js": "assets/vendor.f795a98317800a0f8697b832711ba6ae.js",
  "assets/vendor.css": "assets/vendor.47e5b13a6c66903c00db8ae984063008.css",
  "assets/limber.css": "assets/limber.3af9ba98984fa602106f541342f0cc28.css"
}

Todo:

• tests
• prepend rootURL?
• prepend publicAssetURL?

Questions:

• should we add an option to embed this in the index.html?
• I think the manifest should always be output, even though historically it's been production-only AND opt-in. Thoughts?
• should this be a js file?
• should anything about it be configureable?

[ef4]

What are you actually trying to do with the asset map?

Because I am dubious about the value of asset maps. Historically they have caused lock-in to specific output formats which reduces our ability to optimize builds without breaking the format.

[NullVoxPopuli]

These css imports are not swapped for their chunked versions:
https://github.com/NullVoxPopuli/limber/blob/main/frontend/app/components/shadowed.ts#L23

[NullVoxPopuli]

So, my main use case is valid -- I need to be able to manually specify the CSS I want inside a shadow dom.
The specifics of how are flexible of course, but, I've now tried to import my app css in the app.ts file, and it seemed to resolve, but the manifest from the just-webpack-plugins still does not include CSS 🤔 (though I am still exploring, I see a font referenced that is the same font in my imported stylesheet, but not the stylesheet itself -- lots of options to check on these plugins)

[ef4]

How much do you care about specifically getting the traditional app.css & vendor.css (which are not module-aware and don't go through webpack at all) vs getting styles that you can control in a more module-aware way?

Because if it's just about those two traditional output files, I would rather special-case those and create a way to express a dependency on them from within an app's code.

Whereas if you want to send your styles through webpack and avoid the legacy style pipeline, you can establish your own webpack entrypoint for them in order to take control over their output URL.

Either way, I don't think the solution is an asset manifest. Rather, it's a way to express a dependency on output URLs from within your code. Related to the things discussed in emberjs/rfcs#763

[NullVoxPopuli]

Yeah, I mean having things be more proper and easy with less hacks is def a direction I want to go in.
I'll try adding an entrypoint for my styles and avoid the legacy style pipeline -- this sounds like a step towards getting tailwind JIT working, too. :D