Using `jsx` and `react.render` (ELEVENTY_EXPERIMENTAL=true) to build a 11ty site doesn't seem to be compatible with using hashes and running 11ty with --parallel and --watch (it works without them)

[kuworking]

I am using webpack to transpile js, css, ... and to add hashes to these files

To be able to use those files, I am using html-webpack-plugin to create a json file with the final names

Then I am using this json file in jsx files (templates based on https://github.com/signalkuppe/eleventy-react) where I just import it to read it and to inject the script through <script dangerouslySetInnerHTML={{ __html: xxxx }}></script>

This works if I build the site, and it also works if I serve the site without --watch and --parallel

But if I use both properties

    "serve:webpack": "cross-env NODE_ENV=development webpack --watch",
    "serve:eleventy": "cross-env ELEVENTY_ENV=development ELEVENTY_EXPERIMENTAL=true eleventy --serve",
    "serve": "npm-run-all clean --parallel serve:*",

Then the file created by html-webpack-plugin is not yet there and the process gives an error (of not finding the file)

If I don't delete the file between runs, the 2nd run works since it does find the file there

I am wondering whether there is something I can do about it, something like making 11ty to delay its first execution, to give time to webpack to write these things

[araphiel]

I generally don't use the html-webpack-plugin on multi-page sites.

I simply use https://github.com/shellscape/webpack-manifest-plugin to generate a manifest.

and a small node function to drop the optimized asset into my templates.

// src/_manifest.json (generated by the manifest plugin)
{
  "main.js": "/main.cde180c7fa03d44900ac.js",
  "style.css": "/style.cbbc8fc8b3316cdac96d.css",
}

// utils/shortcodes.js
const fsp = require('fs').promises
const path = require('path')

const webpackAsset = async name => {
    const manifestData = await fsp.readFile(
        path.resolve(__dirname, '../src/_manifest.json'),
    )
    const manifest = JSON.parse(manifestData)

    return manifest[name]
}

module.exports = {
    webpackAsset,
}

// .eleventy.js
const shortcodes = require('./utils/shortcodes')

module.exports = config => {
    // 11ty can use files set in .gitignore. Needed for webpack manifest
    config.setUseGitIgnore(false)

    // Copy assets folder into build - https://www.11ty.dev/docs/copy/#how-passthrough-file-copy-handles-input-directories
    config.addPassthroughCopy("src/templates/assets")

    // Add shortcodes - https://www.11ty.dev/docs/shortcodes/ (import my shortcodes for use with eleventy)
    for (const [name, func] of Object.entries(shortcodes)) {
        config.addShortcode(name, func)
    }

    return {
        dir: {
            output: 'build',
            input: 'src/templates',
            data: '../data',
            includes: '_includes',
            layouts: '_layouts',
        },
        "dataTemplateEngine": false
    }
}

...
<!-- Generic Base Template  -->
<link rel="stylesheet" href="{% webpackAsset 'style.css' %}" />
<script src="{% webpackAsset 'main.js' %}"></script>

This way you can run webpack --watch and your eleventy --serve at the same time with no hassle.

[kuworking]

First of all, many thanks for answering :)

As far as I understand, your code is actually equivalent to using html-webpack-plugin in the sense that both files build a manifest-like file

I mean, I (think I) could use html-webpack-plugin in a similar manner than you're using webpack-manifest-plugin (better said, this is what I'm currently doing)

The difference as I see it is that if you are using shortcodes, then it does work

But if you are using jsx imports with the react/render method, then it does not work, regardless of how you have created the manifest

From your post I do realize the problem is not in generating a webpack file too soon (and a webpack problem), but in the way jsx is integrated in eleventy

[zachleat]

Unfortunately this issue slipped under the radar—I’m finally circling back through some of the old issues on the tracker but I’d love a confirmation that this old one is still relevant before I start debugging! If I don’t hear anything in the next two weeks, I’ll likely close it as stale—sorry (and thank you!)

[kuworking]

Hi @zachleat this is no longer relevant (for me), so feel completely free to close it. In any case, thanks for your dedication!

[zachleat]

Thank you!