Script entrypoint not executing

In latest Sage 10 the sage entrypoint script is not executing.

The script entrypoint file is enqueued and downloaded by browser:

This is the test script:

console.log('app init');

import domReady from '@roots/sage/client/dom-ready';

/**
 * Application entrypoint
 */
domReady(async () => {
  console.log('app');
});

/**
 * @see {@link https://webpack.js.org/api/hot-module-replacement/}
 */
if (import.meta.webpackHot) import.meta.webpackHot.accept(console.error);

No console output from the script (console outputs are generally working from other scripts).

This is generated:

"use strict";(self.webpackChunk_roots_bud_sage=self.webpackChunk_roots_bud_sage||[]).push([[143],{"./styles/app.scss":function(){},"./scripts/app.js":function(){console.log("Test")}},function(s){var t=function(t){return s(s.s=t)};s.O(0,[421],(function(){return t("./scripts/app.js"),t("./styles/app.scss")}));s.O()}]);

This is how the script entrypoint is enqueued:

add_action('wp_enqueue_scripts', function () {
    bundle('app')->enqueue();
}, 100);

bud uses the default configuration (composer create-project roots/sage ...).

I tried to reproduce with stock Sage using both Bud v6.16.1 and v6.20.0 with your exact app.js and didn’t have any issues

Built app script looks like:

"use strict";(self.webpackChunk_roots_bud_sage=self.webpackChunk_roots_bud_sage||[]).push([[143],{"./styles/app.css":function(){},"./scripts/app.js":function(){var s=s=>{window.requestAnimationFrame((async function n(){document.body?await s():window.requestAnimationFrame(n)}))};console.log("app init"),s((async()=>{console.log("app")}))}},function(s){var n=function(n){return s(s.s=n)};n("./scripts/app.js"),n("./styles/app.css")}]);
1 Like

Thank you for checking. It also works in my setup, but I had to clean the acorn cache after switching the theme from the updated one to a newly created one for the new app.js to be used.

1 Like

So testing the existing, updated theme against the newly created one uncovered the underlying issue:

bud.config.js:

  app

  .entry({
    normalize: {
      import: ["@styles/normalize"],
    },
    app: {
      import: ["@scripts/app", "@styles/app"],
      dependOn: ["normalize"],
    },
  })

The normalize entrypoint is declared a dependency of the app entrypoint.
The normalize entrypoint should be enqueued before the app entrypoint.

Rationale behind a separate `normalize` stylesheet The rationale behind is that Gutenberg/FSE enqueues its own frontend `global-styles` stylesheet. This stylesheet is enqueued before the theme `app` stylesheet, which is fine, as it allows the theme to override those default `global-styles` styles. However, when the theme also ships with normalize/reset styles (which is very useful btw.), those styles will override the Gutenberg-specific styles and cause issues. Hence separating `normalize` and `app` styles allows to move the `normalize` stylesheet before the theme stylesheet, fixing the issue.

When this dependency is declared and normalize and app entrypoints enqueued,
app.js is not executed, albeit its <script> element being rendered and fetched by browser. The webpack-specific extra logic inside somehow expects the normalize entrypoint script before execution.

And here lies the underlying issue: The normalize entrypoint is declared with a stylesheet only, no script file. But the manifest.json generated during theme build contains a normalize.js, and no normalize.css. So entrypoints appear, at least in recent Sage 10, being expected to always having a script file, even if just a stylesheet should be used.
Now I could add an empty script file, but this results in an additional, unnecessary file and I would really want to avoid this. Also this behavior looks like a bug.

Edit: The build fails now:

✘ sage ./public [f9899bd0b87f52832cf4]
│
├─ ✘  error
│
│  Cannot read properties of undefined (reading 'config')
│
│
├─ ✘  error
│
│  Cannot read properties of undefined (reading 'config')

I could be wrong, but doesn’t webpack expect every entrypoint to contain a JS file? If so, I don’t think that would be considered a bug with Bud

Adding a JavaScript for the entrypoint fixes the issue and the app script depending on the normalize entrypoint is executed.

Just found bundle($name)->enqueueCss(); that enqueues only the CSS, which is what I want.

IMHO bud should show a warning when the JavaScript file is omitted from an entrypoint, as this causes issues as a depending script not being executed.