Shared Integral and Locker UI code extracted into standalone repository

[Forrest Norvell]

We have a small library of shared Javascript, CSS, and compiled Dust templates that are shared between Integral, Singly's proxy for hosted accounts (and also Singly's website), and the locker itself. @smurthas has been keeping this library synced up as the codebase develops. Because this is a manual process, the two drift out of sync, and this leads to weird inconsistencies in the UI.

I have a solution!

  https://github.com/LockerProject/shared-ui

I extracted the common subdirectories from both Integral and the Locker Project codebases -- with history -- and merged the two together, which was important to reconcile the latest set of @temas's changes.

We just unwound from our last bout of submodule hell, and there might be implications for the build and deployment process, so I don't want to just slam it in there, but I am going to be doing the development for some of my Singly work from it -- keeping everything synced myself. I'd like to get some +1s from devs before I make the change to the actual git repos.

F

[Simon Murtha-Smith]

Probably implied, but I am a total +1. I can't really speak to the deployment situation, but we seemed to be able to handle it before.

[Kristján Pétursson]

If it's helpful, here's Causes' incantation to get submodules into exactly the state we expected to deploy. Might be overkill, but it always worked.

    # Update repos

    run [

     "cd #{deploy_dir}",

     "git fetch",

     "git reset --hard #{revision}",

     "git submodule --quiet sync",

     "git submodule --quiet update --init",

     "git submodule --quiet foreach git reset --hard HEAD",

     "git submodule --quiet foreach git clean -f"

    ].join(" && ")

[Thomas Muldowney]

It totally needed to move into a submodule. Now, can we get the compiled module out of the tree? That's a deploy process requirement, or even startup script.

--temas

[Forrest L Norvell]

I agree. The Integral piece is easy, but the locker side is trickier – make it part of the locker script, maybe? Move to client-side rendering? The LESS renders pretty fast. Is Dust that much slower?

Sent from my iPhone

[Simon Murtha-Smith]

I don't think dust is really slow(er), just seemed like it would require a bunch of extra http requests (presumably, one per template, so 3-4 right now, maybe 5-10 soon enough). I actually felt like moving the LESS to be back end and compile all of them together (and minified) would really be the state to work towards.

[Kristján Pétursson]

+1 getting compile/minify in place while the assets are still relatively small and manageable. We should also land on one of CSS or LESS (or SASS?); it's confusing to look for both.

[Forrest Norvell]

I think that's a great idea, but it does introduce an explicit build step for Integral (aside from running npm), and adds a step to the build for the Locker. I reaaalllly want to get my current story finished, but I'll noodle on this a little after I'm done.

Also in favor of consolidating on LESS (because that's what we have already). As long as we don't start using Coffeescript!

F

[Matt Zimmerman]

We have makefiles in place in both projects, so adding steps is easy (it's
still a one step build for us). There's value in taking care of stuff like
this once per build, and pushing the potential failures away from production
and closer to dev and integration testing.

I'm happy to help with extending the build system if needed.

--
- mdz

[Simon Murtha-Smith]

Additionally, dustjs is dead. I'm recommending that we move to mustache (js implementation) as that seems to be more widely used, maintained, and cross-language. I put my thoughts here and would love some input, but will likely go ahead with this before tomorrow morning unless I hear otherwise.