Issue
I was wondering what would be the best practice to share common libraries and own modules between multiple angularJS projects.
Let's assume that I'm working on two different projects. Both rely on libraries like angularJS, bootstrap etc.
I have a file structure like below:
- Project 1
- index.html
- css
- js
- module A
- module B
- lib
- angular
- bootstrap
- Project 2
- index.html
- css
- js
- module B
- module X
- lib
- angular
- bootstrap
So I was thinking about just creating another directory with all the shared components so that I get sth. like:
- Shared
- angular
- bootstrap
- module B
- Project 1
- index.html
- css
- js
- module A
- Project 2
- index.html
- css
- js
- module X
I have module B written like:
angular.module("moduleB", [])
.service("SB", [function () {/*functionality here*/}]);
.factory("FB", [function () {/*functionality here*/}]);
and would then include it in my Project 1/2 as dependency like:
angular.module("project1", ["moduleB"]);
to achieve this approach.
Would that be the best way? What could be an alternative?
Solution
You can do it that way, but it may give you headaches if you ever want Project 1 and Project 2 to use two different versions of the Shared components. Imagine that you need to release Project 1 with the latest shared components, but Project 2 still relies on a previous version of the shared components. What a mess. Some other options:
- Make the shared components Bower components that could be included into either project as dependencies (see http://briantford.com/blog/angular-bower)
- Compile all shared assets into a mutually accessible URL (see https://medium.com/@KamilLelonek/sharing-templates-between-angular-applications-b56469ec5d85)
- Basically copy/paste components between projects, either manually or using something like gulp (see https://groups.google.com/forum/#!msg/angular/TxE5yoQkG-U/6-vWAZsqn1YJ)
The second option has a lot of moving parts and requires changes to your applications, not to mention the inability to deploy different versions of the shared code in each project. The first has the benefit of being easy to slice into 3 repositories: Project 1, Project 2, and Shared. If Shared is a Bower dependency in Project 1 and Project 2, a simple bower update
will get you the latest version in either project. Or you can lock a project to particular versions of Shared.
Option 3 seems like it gives you the most control, but you will quickly lose track of which version of Shared your project is using. Option 1 solves that.
Answered By - d.jamison
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.