Linking 2 local projects, without the Ugh factor

When working on a large scale application, eventually you’ll want to break it down to one or more product sub projects that all depend on a common project.

This post will discuss how to work with 2 projects properly while still using bower to manage dependencies

So, considering a product project and a my-common project, what you would normally do to link the 2 projects together is either:

• Manual copy

  You would build the my-common project and manually copy the files from the dist folder to a folder in the product project. Ugh. Disgusting…

• Use local artifactory

  You would deploy the my-common project dist folder as a tar on the artifactory and point the product project’s bower dependency  to the artifactory tar as link. It is partially automatic but will still require you to redeploy the common tar on every single little modification. Still Ugh…

• Creating a symbolic link

  This basically means that you will manually create a link from the product project to the my-common project, so that bower_components/my-common in the product project will point to the my-common project dist folder.
  Sure, that’ll work. Except when you want to go live – you’ll have to do some manual lifting anyway and when someone else will checkout the code they will also have to do this manual linking, so yet again – Ugh…

• Actually publish on bower

  This will work just as well as using the local artifactory, but it is only useful if you are willing to have a public github repository for publishing your my-common code or cough up some dough for a private repository to link the bower dependency to. You could create a local Bower repository and deploy there, but even so and in any case, it’s still a manual process of pushing a new version to bower on every single little modification. So, basically, still Ugh…

 

So, if all options are Ugh, what can we do to accomplish that task without the Ugh factor?

Use Bower Link, of course!

Using bower link will not prevent you from having to run the build task, but it’ll be the only thing you’d have to do. It is basically creating a symbolic link, but one that is managed by Bower so that the next time you run bower update it’ll remove the symbolic link and you’ll get whatever is configured in your bower.json file for the my-common dependency version.

It is a classic 1-2-3 punch 🙂

1.  Modify your gruntfile.js file and change your dist folder to be “dist/<your_bower_dependency_name>”  -> so that the dist folder will be dist/my-common. 
2. Navigate to the dist/my-common folder and execute bower link. It will create a reference under your local share folder with the folder name as the dependency name – that’s why we created the my-common folder under the dist folder – to match the my-common dependency name.
3. Now, navigate to your product project folder and execute bower link my-common. 

 

That’s it!
Now, every time you make a modification to your common project, just run grunt build and the newly created dist files will be available for you in the product project.

If you will examine the bower_components folder under your product project, you will see that indeed the my-common dependency is actually a symbolic link to the location of the compiled my-common code.

 

Feel free to use and abuse 🙂
If you modify jsBlackBelt code, please let me know or submit a pull request for the benefit of others.