Add options to define input and content glob pattern for tailwind

[mruoss]

Hey, I love this module! But could we allow a bit more flexible in directory structure? When I create multiple smart cells in one kino library but want to share some elements (e.g. form elements) via a shared folder, this setup doesn't work.

The approach is simple: allow users to pass options for --input and --tailwind-content-glob (or -c, multiple entries are possible). The defaults for the new options are set to the values that were hardcoded before, so this change shouldn't break compatibility.

[josevalim]

For more context, you want this because you want to have two smart cells on Kino Flame because the k8s needs a yaml editor, and that cannot be enabled dynamically, right?

[mruoss]

Right.

Plus, I am thinking about using this for kino_k8s, too.

[jonatanklosko]

I really think we should have a single Flame cell with configurable backend, the same way we have a single Database connection cell. I think we should be able to make the editor togglable with reasonable API, I will look at that later today.

Regardless, I'm ok with these additional config options. But also, I'm thinking perhaps we could have a built-in support for a multi-input configuration for having multiple kinos/smart cells in a single npm project (i.e. with a single build/watch commands). I will experiment with that later.

[mruoss]

I think we should be able to make the editor togglable with reasonable API

That would definitely be better in this case.

But also, I'm thinking perhaps we could have a built-in support for a multi-input configuration for having multiple kinos/smart cells in a single npm project

Would be nice, too. I'm using npm-run-all on kino_k8s, but it's probably harder to use built-in.

https://github.com/mruoss/kino_k8s/blob/main/package.json

Edit: just saw there is also npm-run-all2

[jonatanklosko]

FTR we now have API for toggling editor visibility livebook-dev/kino#467 :)

[jonatanklosko]

I am thinking about this and trying to balance configurability and simplicity. I feel that the more generic we make the script, the less benefit there is (compared to what you already do in kino_k8s), because the user needs to pass a lot of options. At this point I am considering that it may be best for kino-bundler to be opinionated about the directory structure. For example, we could require this:

assets/
├── shared/
│   └── *.js
├── packs/
│   ├── cell1/
│   │   ├── ...
│   │   └── main.js
│   └── cell2/
│       ├── ...
│       └── main.js
├── package-lock.json
└── package.json

Every directory in packs/ would be bundled separately, we would look for main.{js,ts,tsx} as the entrypoint. For tailwind we would glob .{js,ts,tsx} inside the given pack and optionally shared/ (if present). If we did that, we would only need to specify output dir for each pack, such as:

"scripts": {
  "build": "kino-bundler --outdir '../lib/assets/[pack]/build'",
  "dev": "npm run build -- --watch --dev"
}

@mruoss if you have opinions on this, or another idea for how the script should work, let me now :)

[mruoss]

Oh yes I do agree. We can expect a fix directory structure here. You could even go a step further and be opinionated about --outdir too, no? It looks a bit hand-tailored now with the [pack] in it and ../lib/assets is pretty standard...

[jonatanklosko]

Yeah, the main reason for customization is the /build/ suffix I like to add, because it (a) makes clear which part is generated, and (b) in case you need some additional unprocessed assets, you can put those alongside the build directory. But yeah, may as well make that opinionated also!

[jonatanklosko]

@mruoss I've just published a new version with the above changes and updated Kino to use it. Feel free to try it out and if there's anything else needed, in particular for typescript, let me know!