Uniform - Less boilerplate, more code reuse in your portfolio of Elixir apps

This looks really useful, and might be interesting to adapt to make it easier to eject into umbrella apps (one of the systems that I’m working on has client-specific modules).

If I might suggest, an example ejectable repo would be useful to better understand how Uniform works, though.

@halostatue Thanks for your input! Great point about an example repo. That’s next on the list.

Also, great to know there’s potential demand to make it work with umbrella apps. For your scenario, how much granularity would you need? Is an “all or none” approach sufficient? (Either an app is shipped with all the files in an OTP app, or it’s not.) Or would you need to conditionally exclude certain files for certain apps?

Looks great!

I’m not entirely sure what we’d want. The class of apps that we would “eject” are fairly template-able (at least in the beginning), so our primary needs could probably be met if we bothered with a standard template from a repo…but having something that lets us sync certain dependencies across would also be useful.

Hmm, so are we talking white labeling? Or totally separate apps that just share a bunch of boilerplate and some identical features?

We didn’t build this for white labeling, but it would probably work really well for that.

Do they all share the same assets folder?

@cmo That’s up to you. You can configure/tailor it to mostly whatever your setup needs.

If you always want to include everything from assets, use cp_r. (Which is named after File.cp_r and running cp -r on the command line.)

base_files do
  cp_r "assets"
end

If you want to only eject certain files in assets depending on the app, maybe read this part of the Setting up a Phoenix project guide. Here’s a code snippet from there.

base_files do
  file "assets/#{app.name.underscore}/**/*.{js,ts}"
end

Which would eject all files in assets/my_app_name or its subdirectories that end in .js or .ts

All the tools at your disposal are explained in the docs for Blueprint. Most importantly, the base_files macro.

The latter, not white labelling, although that would be an interesting use case for other purposes.

We have a concept of a “client adapter module”, which starts from the same definition, but quickly gets customized to adapt to external client systems and data structures. There’s a lot of shared code within that, though.

@halostatue That sounds like it fits perfectly into Uniform’s model.

Are you currently using private Hex packages for that shared code? Copy-pasting it across codebases? Something else?

Feel free to hit me up on Elixir Slack (@paulstatezny) if you want to talk about specifics that you’re not comfortable sharing here. I’d be happy to walk you through a potential setup that fits your needs.

The current code is…ad hoc and within the umbrella right now. What we’d be looking at retrofitting with Umbrella would be the management of those adapter submodules. I’m thinking we‘d have apps/adapter_template and then somehow do mix uniform.eject --umbrella to know it would be ejecting into the umbrella rather than to a new repo / package. There’s some other bits that would be good (and maybe Uniform could detect).

As I said, though, I’m not even quite sure what it is that we want, and we’ve got a few other overdue upgrade tasks that we’re working through now so we probably won’t be looking at this for a few weeks.