Hanami Assets manifest in wrong place

I’ve been using hanami 2.1.0rc for a while and had successfully worked with hanami assets. However after switching to full 2.1.0 version it all kinda exploded.

I am using the same file structure, and hanami assets watch task to compile.

My assets are all in a slice called main, js entrypoint is in slices/main/assets/js/app.js, it loads an app.css file and does some other minor stuff. It used to work nicely, but now when I run assets watch task from procfile I am getting an error:
Hanami::Assets::ManifestMissingError at /
it is searching under:
/home/mrimp/workspace/libus/public/assets/_main/assets.json"
Which according to the documentation is the correct path, with the main with underscore. However this is not the file structure I am getting.
My manifest is directly in public/ folder so it is public/assets.json. Then there is a assets folder next to it, in it I have my fonts, images etc, but also a folder called main (no underscore). In it there is app.js and app.css

This is my Procfile:

web: bundle exec hanami server
assets: bundle exec hanami assets watch
sidekiq: bundle exec sidekiq -r ./config/boot.rb

app.js

import "../css/app.css";
import "../css/tailwind.css";
import 'htmx.org';
import './htmx.js';

document.addEventListener('DOMContentLoaded', function () {
there is a code that loads a dark theme etc. not really relevant
});

and config/assets.js

import * as assets from "hanami-assets";

await assets.run();

I tried moving the assets outside the slice, into app/ but manifest is still not found and generated in a wrong place. What could be the reason for it? Why is the manifest generated in the wrong place? Can I even customize where it looks for it? Cause the contents of the manifest file look ok.

Hi @krzykamil, thanks for using Hanami!

I think this is a telltale sign: this looks to me like you’re using a couple of mismatching package versions. Specifically:

We made the change to the location of the assets.json manifest between the final rc and 2.1.0 stable. If it’s still a single file being written directly to public/, then you need to upgrade your hanami-assets NPM package.

If this doesn’t fix the problem for you, would you be able to upload a reproduction app (complete with Gemfile.lock and the package-lock.json files)? I’d be happy to take a look into it for you.

@timriley A weird issue I keep having after the upgrade, so far I have been unable to track it down, maybe you will be able to quickly spot it again, whenever you get a minute.

  "app.css": {
    "url": "/assets/_main/app.css"
  },
  "app.js": {
      "url": "/assets/_main/app.js"
  }

My assets.json is missing those two entries, whenever assets get compiled, they are missing from the assets.json file that is nested in the _main slice.
This is extremly weird, since stuff like tailwind.css file that is in the same folder as app.css is included in the manifest.

Here is the app that this happens on.
I checked hanami-assets-2.1.0/lib/hanami/assets.rb:75 and it does read the correct file, it does find the favicon in it, but the css and js entrypoints are not ever compiled, and thus found, in the manifest.
What could possibly be the reason? I’ve stared at my config for hours and haven’t really found anything out of the ordinary.
I’ve went back to my commit where i was on 2.1 rc2 version and went through the upgrade guide again, but no luck there either.

Hey @krzykamil — thank you for sharing all this detail! And you’re not crazy: I was able to replicate this locally too, using the released 2.1.0 version of the hanami-assets npm package.

We must have a bug in that release when it comes to slice asset entry points.

However, when I update the package.json in your app to use the current main branch of this package:

"hanami-assets": "github:hanami/assets-js#main",

Then things work for properly. npm install and then a bundle exec hanami assets compile gives me a public/assets/_main/assets.json that looks like the following:

{
  "app.js": {
    "url": "/assets/_main/app-UJ6FCNFF.js"
  },
  "app.css": {
    "url": "/assets/_main/app-RRZUBCGY.css"
  },
  "favicon.ico": {
    "url": "/assets/_main/favicon-B8DAB077.ico"
  },
  "lib1.png": {
    "url": "/assets/_main/lib1-27767CE5.png"
  },
  "lib2.png": {
    "url": "/assets/_main/lib2-FBDB69C0.png"
  },
  "lib3.png": {
    "url": "/assets/_main/lib3-E9481CEB.png"
  },
  "seshat.png": {
    "url": "/assets/_main/seshat-F66A7922.png"
  },
  "NotoSans-Bold.ttf": {
    "url": "/assets/_main/NotoSans-Bold-F3484BDF.ttf"
  },
  "NotoSans-BoldItalic.ttf": {
    "url": "/assets/_main/NotoSans-BoldItalic-84A524F9.ttf"
  },
  "NotoSans-Italic.ttf": {
    "url": "/assets/_main/NotoSans-Italic-D5B99C1B.ttf"
  },
  "NotoSans-Regular.ttf": {
    "url": "/assets/_main/NotoSans-Regular-9A3CE638.ttf"
  }
}

I’m really sorry for the bother this caused you. And thank you so much for sharing things here!

Next step for me here is to isolate just why this isn’t working with 2.1.0, and why this single PR we’ve merged since then fixes the issue.

Once I’ve done that, I’ll make a 2.1.1 bug fix release ASAP. It might also include Don't mark non-{js,css} dirs as external by timriley · Pull Request #26 · hanami/assets-js · GitHub so the release can fix two bugs at once.

And hopefully using "github:hanami/assets-js#main" as the package source will unblock you and help you continue with development in the meantime.

Thanks again! :bowing_man:

Huh that is a weird case indeed, thanks for looking into it.

Let me know if you need any help with it, I’m liking Hanami a lot so far and would love to contribute in some way.

@krzykamil OK, I think I’ve figured it out! There was something bogus in your package-lock.json, where the 2.1.0 version of hanami assets had a "resolved" URL still pointing to a commit in the GitHub repo:

"node_modules/hanami-assets": {
  "version": "2.1.0",
  "resolved": "git+ssh://git@github.com/hanami/assets-js.git#0627aa2a5fe2784f80d5590b070548085123f882",

This stood out to me because all the other packages in that file had "resolved" URLs pointing to the proper NPM registry, e.g.

"resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.11.tgz",

Since hanami-assets 2.1.0 is a proper release in NPM, I wondered why it didn’t have a registry.npmjs.org URL like the one above.

To fix this in your app, I blew away package-lock.json as well as node_modules, and reinstalled fresh:

rm -rf package-lock.json node_modules
npm i

This resulted in the following section of diff for package-lock.json:

     "node_modules/hanami-assets": {
       "version": "2.1.0",
-      "resolved": "git+ssh://git@github.com/hanami/assets-js.git#0627aa2a5fe2784f80d5590b070548085123f882",
-      "license": "MIT",
+      "resolved": "https://registry.npmjs.org/hanami-assets/-/hanami-assets-2.1.0.tgz",
+      "integrity": "sha512-nOanYSZgATOrZofZXUwH7E1usTMbnECptaB6nfZCqNuE3QFCpRinOhdGJ8ndZPc1wEKVrs4VS85dQ0fLCa87Iw==",
       "dependencies": {
         "esbuild": "^0.19.0",
         "fs-extra": "^11.1.0",

That’s looking better!

Then a bundle exec hanami assets compile resulted in the following public/assets/_main/assets.json:

{
  "app.js": {
    "url": "/assets/_main/app-FIQKTEJF.js"
  },
  "app.css": {
    "url": "/assets/_main/app-RRZUBCGY.css"
  },
  "favicon.ico": {
    "url": "/assets/_main/favicon-B8DAB077.ico"
  },
  "lib1.png": {
    "url": "/assets/_main/lib1-27767CE5.png"
  },
  "lib2.png": {
    "url": "/assets/_main/lib2-FBDB69C0.png"
  },
  "lib3.png": {
    "url": "/assets/_main/lib3-E9481CEB.png"
  },
  "seshat.png": {
    "url": "/assets/_main/seshat-F66A7922.png"
  },
  "NotoSans-Bold.ttf": {
    "url": "/assets/_main/NotoSans-Bold-F3484BDF.ttf"
  },
  "NotoSans-BoldItalic.ttf": {
    "url": "/assets/_main/NotoSans-BoldItalic-84A524F9.ttf"
  },
  "NotoSans-Italic.ttf": {
    "url": "/assets/_main/NotoSans-Italic-D5B99C1B.ttf"
  },
  "NotoSans-Regular.ttf": {
    "url": "/assets/_main/NotoSans-Regular-9A3CE638.ttf"
  }
}

Perfect!

So: there’s no bug in the 2.1.0 release of hanami-assets.

Somehow your app locked in a version in git that wasn’t doing the right thing. Interestingly, the 0627aa2a5fe2784f80d5590b070548085123f882 sha is actually a commit in this currently open pull request, so I think we just need to be extra careful about testing that before merging and making a new release.

Let me know how you go in light of the information above!

I’ve just confirmed this.

If I put the branch for that PR in your package-lock.json:

"hanami-assets": "hanami/assets-js#allow-references-to-files-outside-js-css-dirs",

And then npm i and compile the assets, it gives me the incorrect manifest (missing files) we’ve discussed above.

I’ll make sure I figure out what’s going on in this PR before merging (and ideally catch this via a test somehow).

Damn, you are right of course. I was only deleting node_modules when debugging this, didn’t think about the package-lock. Good thing 2.1.0 is ok then.
Thank you for looking into this.

Let me know if you need/want some assistance on the branch

I figured out why Don't mark non-{js,css} dirs as external by timriley · Pull Request #26 · hanami/assets-js · GitHub wasn’t working — I had some changes to dist/ (compiled JS files) that I hadn’t pushed to match my changes to the (TypeScript) files in src/ :person_facepalming:

If you want to try that branch again with your app, you should see you have a full public/assets/_main/assets.json just like the one I pasted above.

1 Like

This is now released has hanami-assets (npm package) v2.1.1.