# Script entrypoint not executing

**URL:** https://discourse.roots.io/t/script-entrypoint-not-executing/26540
**Category:** sage
**Tags:** bud, sage10
**Created:** 2024-01-12T21:31:07Z
**Posts:** 6

## Post 1 by @strarsis — 2024-01-12T21:31:07Z

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 ...`).

---

## Post 2 by @ben — 2024-01-13T13:55:08Z

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

 ![image](https://discourse.roots.io/uploads/default/original/2X/6/624e9bcf93bfcab82131a805b48c9cb9f087b109.png)

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")}]);
```

---

## Post 3 by @strarsis — 2024-01-13T14:41:03Z

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.

---

## Post 4 by @strarsis — 2024-01-13T15:27:06Z

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')
```

---

## Post 5 by @ben — 2024-01-13T15:54:20Z

> [@strarsis](#):
>
> Also this behavior looks like a bug.

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

---

## Post 6 by @strarsis — 2024-01-13T19:09:32Z

> [@ben](#):
>
> 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.