Added an issue to track on the Bud repo
Cool, thanks!
Just wanted to add that in my case even with yarn build the assets are not loaded, the same error occurs as in yarn dev.
Another update here!
@slowrush Yeap, you were right here:
I did unsecure it since the second option didn’t work for me either.
My setup for dynamic js is inspired by this.
So, I have a publicPath.js file inside scripts folder which has this line:
__webpack_public_path__ = ASSET_PATH
I import this file in the main entry app.js and that’s what made dynamic imports work (in staging and production at least).
I removed this import declaration and now the JS files are working correctly on the dev server.
So, it means that I need to remove this line working locally, but don’t forget it to push it, because it would break the scripts on production.
Still, I can’t see the SVGs because they are from the proxy link eg: http://local.test
Security Error: Content at http://localhost:55871/ may not load data from http://local.test/app/themes/local-theme/public/spritesheet.svg.
I have used @asset to show the SVGs files. Also, the path is wrong.
@slowrush Out of curiosity, can you share what is your setup for Bud and JS that you use to load components dynamically?
I am using Bud 5.
I’ve had to put dynamic imports on the back burner because of this issue + a tight deadline.
Switched back to importing assets per ACF block via Roots\bundle (bundle('block-name')->enqueue();) + use browser-sync for live reload for the time being. If I make any progress I’ll be sure to post back here.
I know a fair few folks have solutions working, hopefully, they’ll follow up but I’ve hit a few too many walls 
dynamic imports are pretty simple.
make sure your publicPath is set in your bud config:
bud.setPublicPath(`/app/themes/sage/public/`)
In your application code you can import dynamically:
// test.js
console.log('test loaded')
// app.js
const main = async () => {
const condition = document.querySelector(`.foo`)
if (condition) {
await import('./test.js')
}
}
main()
It works for css as well:
// test.css
body {
background: black;
}
// app.js
const main = async () => {
const condition = document.querySelector(`.foo`)
if (condition) {
await import('./test.css')
}
}
main()
It’s a little weird to do a dynamic import on css (IMO). I’d prefer to load the css in a js module and dynamically import that:
// test.css
body {
background: black;
}
// test.js
import './test.css'
console.log('test loaded')
// app.js
const main = async () => {
const condition = document.querySelector(`.foo`)
if (condition) {
await import('./test.js')
}
}
main()
Another example I just tested on vanilla sage. This one will only load the css to change the page background if ?condition=true is appended to the URL:
// resources/scripts/app.js
const init = async () => {
let params = new URL(document.location.toString()).searchParams;
let condition = params.get('condition');
if (condition) await import('./test.js');
};
init();
// resources/scripts/test.js
import '@styles/test';
console.log('test loaded');
/** resources/styles/test.css */
body {
background: black;
}
1 Like
There is too much going on in this topic. You should make a separate topic for any problems with SSL certificates.
And the dynamic JS file loads correctly on the proxy server?
(Or is this more a response to slowrush?)
If you run that code with yarn bud dev the code will work on the dev server.
If you run that code with yarn bud build the code will work on the proxy (and in staging, production, etc.)
The roots.io frontend uses this exact approach.
Thanks for you detailed answers.
I tried what you wrote above in a new sage theme with bedrock, but in the yarn build it still doesn’t seem to work.
.setPublicPath('/app/themes/eri-test/public/')
but I get this error
ChunkLoadError: Loading chunk 457 failed. (missing: http://bedrock.test/app/themes/eri-test/public/js/dynamic/457.js)
which is essentially the error of this thread and the one that slowrush opened the Github issue.
I don’t know what’s up with that.
- Does
/app/themes/eri-test/public/js/dynamic/457.jsexist on disk? - Is
/app/themes/eri-test/public/the actual public path?
Dynamic imports just work out of the box. There is no reason to set anything like ASSET_PATH or use any webpack magic comments to use them. I don’t doubt that something isn’t working for you and maybe I just don’t understand the question.
If you want to use an image you can just import it:
import { domReady } from "@roots/sage/client";
import test from "@images/test.png";
const main = async () => {
await import("./test.js");
document.querySelector("#app").innerHTML = `
<div>
<img src="${test}" />
</div>`;
};
domReady(main);
import.meta.webpackHot?.accept(console.error);
Ok, I created a new sage theme (since I mistakenly deleted the current one I was using for tests) and now it’s working as you said.
Still, the situation in my current project is not resolved by this. After days of trying to debug this issue, I still haven’t figured it out.
I have pasted my bud.config.js file in the thread starter.
If I try to set .setPublicPath() as you propose, no asset is loaded because the final link is wrong eg
https://local.test/app/themes/local-theme/public/dev/public/app/themes/local-theme/public/app.6e4d64.css
while if I let it empty, the assets are loading ok, but not the chunks:
ChunkLoadError: Loading chunk 570 failed.
(missing: http://local-site.test/570.9361df.js)
Maybe my project is messy and you guys can’t reproduce it, so I’ll have to spend more time on it 
p.s. I tried to upgrade Bud from 5 to 6 (following this), but I got this error when trying to build the assets:
error [err_require_esm]: require() of es module ./node_modules/chalk/source/index.js
Probably will open a new issue if this persist.
I think it’s because you are defining ASSET_PATH. Don’t do that.
The second issue is because you are trying to require chalk somehow. I’m not sure why that is but I don’t think it’s a problem with bud.js. I don’t think I will be able to help you without a repo that reproduces the issue.
Hello again @kellymears !
Sorry to disturb again with this issue, but I think I finally managed to reproduce it in a fresh theme.
Here you go: GitHub - erip2/eri-sage-test
This theme is taken from here Release v10.1.0 · roots/sage · GitHub because in the current project I still use Bud v5.5.0.
You can install it and try: yarn dev and yarn build.
In the yarn dev case things work fine.
In the yarn build case there are errors because assets are not found:
GET http://bedrock.test/app/themes/eri-5.5.0/public/app/themes/eri-5.5.0/public/app.488aeb.js
[HTTP/1.1 404 Not Found 324ms]
If you set the publicPath to empty (.setPublicPath("")), on yarn dev things are working fine, but on yarn build → Uncaught (in promise) ChunkLoadError: Loading chunk 806 failed.
I test the dev on bedrock.test:3000 and build on bedrock.test
Thank you!
I’m sorry, but v5.5.0 was released 236 days ago; you should update. There have been 496 commits since this code was released.
Bump everything to 6.5.3 and replace @wordpress/browserslist-config with @roots/browserslist-config and you should be good.
{
"name": "sage",
"private": true,
"browserslist": [
"extends @roots/browserslist-config"
],
"engines": {
"node": ">=16.0.0"
},
"scripts": {
"dev": "bud dev",
"build": "bud build",
"translate": "npm run translate:pot && npm run translate:js",
"translate:pot": "wp i18n make-pot . ./resources/lang/sage.pot --ignore-domain --include=\"app,resources\"",
"translate:js": "wp i18n make-json ./resources/lang --pretty-print"
},
"devDependencies": {
"@roots/bud": "6.5.3",
"@roots/bud-tailwindcss": "6.5.3",
"@roots/sage": "6.5.3"
}
}
1 Like
I did so and with a basic config, yeap, things are working fine 
…
…but one of the reasons that I couldn’t upgrade some time ago to the major version 6 is this error Plugin error after upgrading Bud to ^6.3.5
You can also check my whole bud config on this thread starter.
And if I try to upgrade it to 6.5.3, then on the VS Code I get an on each bud instance, eg .entry({... that says:
any
Property 'entry' does not exist on type 'Bud'
and on the browser after running the dev:
Uncaught Error: Module build failed (from ./node_modules/babel-loader/lib/index.js):
Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/chalk/source/index.js from /Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/traverse/node_modules/@babel/highlight/lib/index.js not supported.
Instead change the require of /Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/chalk/source/index.js in /Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/traverse/node_modules/@babel/highlight/lib/index.js to a dynamic import() which is available in all CommonJS modules.
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/traverse/node_modules/@babel/highlight/lib/index.js:14:14)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/traverse/node_modules/@babel/code-frame/lib/index.js:9:18)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/traverse/lib/path/replacement.js:13:18)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/traverse/lib/path/index.js:28:28)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/traverse/lib/context.js:8:13)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/traverse/lib/traverse-node.js:8:16)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/traverse/lib/index.js:34:21)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/helper-replace-supers/lib/index.js:20:17)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/helper-create-class-features-plugin/lib/fields.js:13:28)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/helper-create-class-features-plugin/lib/index.js:32:15)
at Object.<anonymous> (/Users/erip2/Documents/local-theme.com/dev/public/app/themes/local-theme/node_modules/@babel/plugin-proposal-class-properties/lib/index.js:10:40)
at async Promise.all (index 0)
js app.js:1066
See the v6 upgrade guide:
What does your package.json look like? Are you including your own import of babel? If you are importing babel it is on you to keep that dependency up-to-date.
What do you need to do in order to share your repository as a reproduction case? This is the only way forward in order to help you. There is something wrong in your project but it is never going to be debugged with Discourse as a devtool. @ me when you have a minimal reproduction and I’ll be glad to take another look.
Ok, finally I managed to fix this 
I managed to upgrade to version 6 and fix my issues.
About this:
I removed the // @ts-check on top the bud.config.mjs file.
And about this:
I just deleted my node_modules folder and ran yarn again and this error didn’t show up.
About the other topic I referred here, I am not sure how that was fixed, but I would suggest others take a good look at the function chain in the bud config.
Thanks, guys!
Both of these errors:
Property 'entry' does not exist on type 'Bud'
and
Type 'import("project/node_modules/webpack/types").Compiler'
is not assignable to type
'import("~/Library/Caches/typescript/4.7/node_modules/webpack/types").Compiler'
are related in that they are not actual runtime errors, they are Problems flagged by vscode’s static analysis. In the case of the second error you can see that the problem is with some stale cache vscode is pulling from ~/Library/Caches/typescript/4.7 not matching the type described by node_modules/webpack/types. bud.js obviously has no control over that mismatch.
For more information on vscode type acquisition and type checking:
Also worth looking at the vscode docs on jsconfig.json. This file gives you a lot of control over this and many other things you’ll likely one day encounter working with JS in your project. Totally worth configuring:
Anyway, removing//@ts-enable will “fix” both of these issues, but they were never going to cause your project to not build. You could add //@ts-enable back and it won’t cause any problems aside from adding noise to the editor.
You could also add //@ts-ignore above the line that is emitting the problem if you wanted to keep the typechecking everywhere else. Maybe try to remove the ignore the next time you update, maybe the error will have resolved itself. I think the value added from the //@ts-enable intellisense makes it worth figuring out how to keep it. But, whatever works for you.
Glad you’re all sorted out.
1 Like