Might want to update the docs & code about `before_webindex_write`

[seivan]

It exits as an event type, but waitingFor on it, does nothing. Afaik, I can't see anywhere in the code where its event type would be used. Might also want to remove the actual type

//fuse.ts
function myCustomWebIndexTransformPlugin(options?: any) {
    return async (ctx: Context) => {


        ctx.ict.waitFor(
            'before_webindex_write',
            async (props) => {
                console.log("TEST")
                console.log(props.bundles[0])
                props.fileContents = "REMOVE ALL"

                return props;
            },
        );
    };
}

class Builder {
    runServer;
    getConfig = () =>
        fusebox({
            target: "browser",
            entry: "src/index.tsx",
            webIndex: {
                template: "src/index.html"
            },
            plugins: [myCustomWebIndexTransformPlugin()],

            cache: true,
            devServer: this.runServer,

        });
}
const { task } = sparky<Builder>(Builder);

task("default", async ctx => {
    ctx.runServer = true;
    const fuse = ctx.getConfig();
    await fuse.runDev();
});

task("preview", async ctx => {

    ctx.runServer = true;
    const fuse = ctx.getConfig();
    await fuse.runProd({ uglify: false });
});
task("dist", async ctx => {
    ctx.runServer = false;
    const fuse = ctx.getConfig();
    await fuse.runProd({ uglify: false });
});

[nchanged]

@seivan there was a PR that was utilising it. But it was closed. It was supposed to help to synchronise the modifications to index

[seivan]

No, I understand that, but it could also doable via.... if it wasn't for the disorganized structure of the output (props)

ctx.ict.waitFor(
            'complete',
            async (props) => {
                const file = fs.readFileSync("./src/index.html", 'utf8').toString()
               const updatedFile = someTemplateEngine(file, props.bundles)
                fs.writeFileSync("./dist/index.html", updatedFile)
})

Off topic and not related to this issue, but to the one I opened earlier. https://github.com/fuse-box/fuse-box/issues/1899

The approach to generating the html is flawed. Instead of shoving outright <script> tags, give the building blocks for user to make themselves, and offer an out of the box template that uses those building blocks internally. It could actually just rely on the code above and be introduced as a plugin, but in order to do that, a lot of things have to be changed to offer a decent bundle output structure that can accommodate it.

As of now, there is now way to add CSP hashes based on output contents. The types and current structure offered are a mess, IBundleWriteResponse is too disorganized to be able to figure out what I am actually getting. It's a good start since it's using TS ;-), but not there yet.

Also I can't see a way to control the entries to individual output files in the types, documentation doesn't match the current code base. All I can see is

            entry: ["src/index.tsx", "src/other_index.tsx"],

and you can only pass a single key app as an output(?) otherwise there's a type error.

const config: IRunProps = {
    bundles: { app: "index.$hash.js" }

}

But what if I want to compile two entries files with two different settings (say ES5 and ES6) and not merge them, but get them as a bundle to inject into my html template? I assume this is supposed to tackle that?

I've started with

                props.bundles.forEach(b => {
                    b.bundle.source.entries.forEach(e => {

And using the priority for sorting and getting the actual name via publicPath so I can know what is what. But requiring manual sorting and detective work with parsing paths to figure out what file is what just leaves a bad taste.

Maybe I want to load some entries via <script src=.. and others via dynamic script tags from a template string with its SHA hash for CSP.

I've been investigating Fusionbox for the last day, including going through the code base, and I see potential, mostly because the code base is actually quite well done but it's API isn't well thought out, but unfortunately won't be able to use it which is a shame.

TL;DR: As of today it doesn't seem to offer anything supporting best practices or something remotely close to production ready.

Sorry for the off topic rant, I hope the feedback is helpful, if not feel free to close it.

[nchanged]

@seivan thanks for your feedback! I do agree that webindex deserves a re-write. Please feel free to propose an architecture that would fit any needs. But I think the initial implementation should be as simple as possible.