search

zenbones-theme / zenbones.nvim

🪨 A collection of contrast-based Vim/Neovim colorschemes
MIT License
682 stars 48 forks source link

Refactor build #43

Closed mcchrish closed 2 years ago

rktjmp commented 2 years ago

Any shipwright painpoints?

mcchrish commented 2 years ago

It's working great so far. I like that I pretty much translated the old build system into shipwright mostly keeping the same workflow. For example

before: https://github.com/mcchrish/zenbones.nvim/blob/265ab617dec5bd9bab1b8a24012fee7c76ac9788/lua/zenbones/template/iterm.lua after: https://github.com/mcchrish/zenbones.nvim/blob/main/lua/zenbones/shipwright/runners/iterm.lua

There are probably more ways to clean it up but as long as the output is correct.

rktjmp commented 2 years ago

:tada:

I see you used make_env's merge param.

https://github.com/mcchrish/zenbones.nvim/blob/6a87667dd4005189732eb339fd6bd5c14c711d9d/lua/zenbones/shipwright/init.lua#L10-L17

I actually forgot I left that in. Looks like it's useful though, so I will leave it there. (I was going to use it myself but opted for direct requires in the build file, but I only have one scheme to make.)

I wonder if a proper API for it should exist for it. I hadn't really considered having "runners" as explicit types either but it makes sense.

Maybe one day something like

shipwright.run_with_(extra)_env(runner, {...})

Would abstract your boiler plate out for other people.

At the same time, the API is very light now, not sure how complicated I want to make it. It already has sort of weird syntax with the variable arity and {transform, arg, arg} stuff.

Thanks for testing it out.