WIP: Use bun for all front end concerns

[wout]

Changes

This is just the current state of the Bun implementation as a first draft. This works locally in development in the Fluck website app, and all tests pass as expected.

Changes needed in the Lucky app itself are:

Procfile.dev

assets: bun run dev

package.json

  "scripts": {
    "build": "bun lib/lucky/src/bun/bake.js",
    "dev": "bun run build --dev",
    "prod": "bun run build --prod"
  },

src/components/shared/layout_head.cr

bun_reload_connect_tag

Other

• Run bun run prod for deployment
• Add the shared config/bun.json file (optional, all fallbacks are in place)

Questions

I'd like to add more tests but I'm a bit stuck. More specifically I'm a bit confused by the Lucky::AssetBuilder::Mix and Lucky::AssetBuilder::Vite classes. They only ever seem to be used in the test suite. What's their purpose? Are these preparations for the pluggable asset system?

What confuses me is that they are part of src but only used in spec. Of course I can add a Bun variant with a test suite, but I thought I'd ask first.

[jwoertink]

This is so awesome! And I love that you added some tests for the javascript stuff too. That'll be a huge help in maintaining it. Thanks for putting this all together. I feel like this pushes Lucky into some more much needed modern setup 🙌

As for the asset build system...

What's their purpose?

These were part of what I was talking about possibly reverting. This was added in order to make the asset system pluggable. I'm still not sure if I should revert them or not. The idea would be that you configure whichever build system you wanted to use, and then Lucky internally knows when to call the different commands it needs for each... However, I don't think it was ever completed because we got stuck on just trying to make Vite work out of the box.

On the one hand, it's basically useless code sitting around doing nothing so probably should be removed... On the other hand, we could actually just use it and then maybe the asset builder wouldn't need weird args like legacy: true or use_vite: true... though, I'm not sure if it would be possible to even configure at the macro level 🤔 I don't know, I'm a bit torn on it. I guess worst case is we remove it and just add it back later if we really want?

[wout]

Thanks! Bun feels really snappy and I love that it doesn't require any dependencies. Not even for the test suite.

A pluggable asset system is a great idea in itself I think, and adding the Bun counterparts wouldn't be a lot of work. But I'm not completely clear when it would be invoked. Would that be at compile time like the current AssetManifestBuilder? Because it would be great to modularise that part.

The only thing is that if it's kept around, the Vite implementation should be equally usable as the Mix and Bun versions. We could harvest the good parts from the LuckyVite shard which works, but is it worth the effort? It's not that any of us has the spare time to put in the effort into something that may not even be used at all 😄.

UPDATE:
For the flags on the load_manifest macro, we could rework that so it's less messy:

• load_manifest(from: :bun) (default)
• load_manifest(from: :vite)
• load_manifest(from: :mix)

And then the frontend would require a bit of manual configuration which is inevitable I think.

[wout]

I don't know, I'm a bit torn on it. I guess worst case is we remove it and just add it back later if we really want?

My two cents on this. For now I think it may be better to park it. It's only once every five years you'd need to reconsider the asset build system, and I suppose you don't want to add support for every bundler available. Lucky has always been opinionated (PostgreSQL, LuckyHTML, Laravel Mix, etc.) and personally I don't feel that should change for the bundler.

It would be good to restructure the asset manifest builder a bit so that it's easier to add different manifest parsers, and switch between the build systems with a single argument on the load_manifest macro. But that's more about maintainability than pluggability.

[wout]

Is there something I can still do for the Bun implementation? Like reworking the asset manifest builder to make it switch between Mix/Vite/Bun? Or if you need more time to think about it, that's fine with me. I don't want to rush you.

This weekend I'll be mostly working on the Lucky::Attachment proposal, which is going well too. So plenty to do anyway 😄.

[jwoertink]

I like your suggestion of changing the load_manifest with from: :bun, etc... And I agree, there will still be some sort of manual configuration for the frontend, but as long as the backend gets out of your way to allow you to do that , then it should be good 👍

I see the title still has WIP, is this fully ready for review? I poked around real quick, but haven't had a free moment to really get my head in that space just yet. I plan on taking a look this weekend or next week at the latest though.

Thanks again for all this work. This is huge! 🙌

[wout]

Great, then I'll restructure the asset manifest builder as well to work with all bundlers.

And yes, this is still a WIP. Hopefully by the end of this weekend it will be ready for a first review round. I'll remove the WIP from the title and let you know when it's ready.