removing git submodule in favor of bower

[tomfriedhof]

Moving the foundation-sites dependency to bower rather than managing with a git submodule.

This will help make the setup process downstream a little simpler by removing a couple setup steps here: https://github.com/activelamp/iamucla-logon/

[erutan]

That makes sense from a technical standpoint - however there are times where I'll go through loops of making quick changes to the fork by pulling some code out of a project partial and universalizing it, updating in logon/ssoui, testing changes, etc. It's simpler to just run the git submodule update command than to look up what the last commit change was, update bower.json, then run bower update.

motion-ui should have been updated to what it's resolving to, but I'm fairly sure what-input shouldn't be resolving to ~2.0

[erutan]

I'll revisit bower pinning when foundation 6.3 comes out - it's at RC1 now. It'll have some breaking changes (anticipated on my end only) and zurb will be doing a pass on the template and framework.

[bezhermoso]

Hi @erutan,

I'm facing some problems with integrating work on this repo into our build & code-base and vice-versa, specifically because of limitations relating to the use of git submodules in this repo and git subtrees in our code-base, which we require in our build.

Are you familiar with bower link? I think it can be useful to support your workflow and ours quite well.

Development for ucla/logon

This will do away with Git submodules and utilize bower link functionality to aid development but keeping version info of foundation-sites within bower.json.

Directory structure:

<PROJECT>
    │
    ├── foundation-sites # The `ucla/foundation-sites` repo
    │   └── # Dev work & patching of `zurb/foundation-sites` are done here.
    │
    └── logon # The `ucla/logon` repo
        └── # Dev work for ucla/logon are done here.

Set up for bower link:

1. Create a global link for foundation-sites to <PROJECT>/foundation-sites:

   $ # From UCLA project folder
   $ cd <PROJECT>/foundation-sites
   $ bower link
   

2. Use Git reference for foundation-sites in logon/bower.json:

   {
     "dependencies": {
       ...
       "foundation-sites": "ucla/foundation-sites#edc4c1ed68d7b35250f433c472727f35c4144436",
       ...
     },
   }
   

   After this modification it might be a good idea to run rm -rf bower_components/foundation-sites && bower install to reset the state.

3. Link <PROJECT>/foundation-sites to <PROJECT>/logon:

   $ cd <PROJECT>/logon
   $ bower link foundation-sites
   

   This will convert logon/bower_components/foundation-sites to a symlink to <PROJECT>/foundation-sites so that any changes there will affect this project.

Publishing ucla/logon

The Git reference for foundation-sites in logon/bower.json should be updated so that Bower will pull the correct version during builds. Here is a command I wrote up which can be used to do this reliably:

$ cd <PROJECT>/logon
$ sed -i '' "s/foundation-sites#[a-z0-9]*/foundation-sites#$(cd bower_components/foundation-sites; git rev-parse HEAD)/" bower.json

This will update the Git reference to whatever the SHA1 hash of the latest commit is in <PROJECt>/foundation-sites.

---

What are your thoughts?

[erutan]

On my end it'd be simpler to just not pin foundation-sites to a commit hash and just pull latest via bower, that'd give me the same ease of use as I have now.

There's often minor changes to my fork of foundation I have to test in project (or test new components I've abstracted into it across projects), so repeatedly editing bower.json in a short period of time is less than ideal (I could edit in whatever app repo I'm in, then backtrack and copy changes into ucla/foundation, but that's rather crap).

Having that difference between forks would have less architectural impacts and should be fine to just merge whichever way we want locally.

[bezhermoso]

With bower link you wouldn't really need to edit bower.json in order to get the correct versions during development; its just going to be a symlink to wherever your fork to foundation-sites lie. For all intents of purposes, bower_components/foundation-sites will still appear as a directory that contains your fork, which you can edit, commit to, etc. in real-time.

In a sense, you will always have a global link to your fork of Foundation for Sites in your machine that you can drop in to any project via bower link foundation-sites.

The only time it is essential to update bower.json is when committing work for ucla/logon that actually requires the changes in your fork of Foundation for Sites -- that way the deployment build knows to pull from that version. It's the equivalent of updating the git submodule reference (git add bower_components/foundation-sites in the current workflow).

---

With all that said, I'm not saying that the current setup simply does not work. It is just not a very sustainable way of keeping our fork of ucla/logon code-base in sync with your work, and vice-versa.

[bezhermoso]

Oh, and by "build" I mean the deploy build. gulp build will read from wherever your local fork is even if bower.json is not yet updated.

[erutan]

If I'm understanding correctly the bi-directionality makes things a bit simpler on my end- the changes made to bower_components/foundation-sites in logon/ssoui/etc would be mirrored to the original repo location, which makes testing a little less blind (oh another syntax change in another partial, etc) and saves me from running the submodule update command.

I guess I'd just need to be careful about having changes in an application prototype repo that weren't committed to ucla/foundation-sites in case I ran bower install for some other component and overwrote those changes with an earlier hashed commit release e.g. "foundation-sites": "ucla/foundation-sites#edc4c1ed68d7b35250f433c472727f35c4144436", - but that'd happen even if unpinned (grab last commit).

The git submodule pulling into bower_components was viewed as a bit of a hack on my part (I had started that workflow when things were a lot simpler), so I'm not tied to it if I can get similar or better functionality.

[erutan]

I could have just been having bower pull the repo unpinned via bower link - it was something I sort of looked into but didn't see any advantage to in the past, but perhaps didn't look it into it enough. :)

[bezhermoso]

Yeah, that would be one advantage; that all bower_components/foundation-sites in various application prototypes would point to the same repo location if you'd like (via bower link foundation-sites within said prototypes).

I also tested doing bower install or bower update, and they don't do anything harmful like resetting uncommitted changes or anything like that. Executing those does not remove the link either, so it's relatively safe to do (contrary to what this blog post say; must have changed within the last 3 years). If Bower somehow decides to pull whatever is on GitHub, it does so by removing the symlink instead of actually overwriting the contents of bower_components/foundation-sites, which is safe and sane. Your fork will remain untouched.

[erutan]

I'm good with it, I'll pull in these changes this evening / test around on my side. :)

[bezhermoso]

Cool, thanks! Let me know what sort of problems you run into if any and we can rehash the optimal solution together.

[bezhermoso]

@erutan

Here is a new PR: https://github.com/ucla/logon/pull/17. It supercedes this one.

You can close this PR and we can resume discussion there.