Maintaining a PhoneGap Hybrid/Web App Codebase - javascript

I'm investigating the complexity involved in maintaining a cross-platform (web, ios, android) phonegap codebase that allows for platform specific code (and assets/tests) as simply as possible.
The current best approach I'm taking is to use grunt to build the code of a typical web app, and then use the grunt-phonegap module to generate the respective phonegap projects.
I'm confident this will work, however for my phonegap projects, I know I'm going to need to make use of some specially written plugins to make use of some device capabilities (these aren't typical cordova plugins)
I'm wondering if anyone has figured out an approach for maintaining a codebase that can adapt to different platforms and requirements. Javascript has no #IF_DEF functionality, but would it be possible to implement something like that using grunt?

I recently had the same question myself. I couldn't really find much online regarding this so I decided to deep dive into Grunt, Node, and Git.
Grunt and Node
In the root folder of my Cordova projects (alongside the www, platforms, merges, and plugins folders) I have a grunt project. I store modular JavaScript files and CSS files that may or may not be platform dependent inside a src folder inside the root of the Cordova project. This grunt project builds the JavaScript and CSS stored in the src folder and places the resulting files into the www or merges folder as appropriate.
I even wrote a grunt task that will make a production build of the app by optimizing and minifying css, javascript, and html templates, then rebuilds the Cordova platform projects to include these production files.
Because there is no #IF_DEF in JavaScript, I have to use Grunt (mentioned above) to build out the JavaScript for each platform. I modularize almost all of the JavaScript functions by platform. If there are no platform differences for that function (no native hooks), I only need one file. If there are differences, I need to create a separate file for each platform for that function. For example, my Cordova onDeviceReady and onResume function usually differ from platform to platform. I create files called
CordovaEvents-ios.js and CordovaEvents-android.js
Inside the package.json file, I describe the "features" I want in my app. CordovaEvents is an example of a feature.
I also support "arguments". I use the same approach above in the file names of the modular files. An argument could look like this
CordovaEvents-ios--production.js and CordovaEvents-android--production.js
In this case the code needed in a production app will differ from non production code. I can simply pass this argument (or list of arguments) during the build process, and the correct files will be picked up and built. I think this most closely addresses your question if there is an approach to maintaining a codebase that can adapt to different platforms and requirements. The requirements are the feature names and arguments. The argument can be anything you want, maybe using one plugin or another plugin.
I also describe the platforms I want to support ("iOS", "Android", and "Desktop"). Grunt processes each platform in a MultiTask, and then looks at the features I want to support. It will try to find a file called feature-platform.js. If it cannot find this file, it will just try to look for feature.js. After I concatenate all the functions together needed for the platform, it will copy the file over to the merges folder for iOS or Android. Typically all the files kept in the WWW folder in the root project will work on a desktop because there are no native Cordova hooks... this allows me to debug in Chrome. All the files that contain native hooks are stored in the merges folder. Once the Cordova project is built for the respective platform, the code can be tested in a device simulator.
If you are new to Grunt I would strongly suggest taking a look a their getting started guide.
http://gruntjs.com/getting-started
Git
I also employed Git to version my code. I used SourceTree to create the Git repository in the root folder of my Cordova project, and have a remote repository on my Mac Mini server that I can push my commits too. This allows us to have a backup copy of the code, and makes it so my team can also work on the code out-of-band.
I Git ignore the following folders:
node_modules
plugins
platforms
plugins
All the other files and folders contained in the root directory of my Cordova project are versioned. I used the following link as a reference to help define my Git strategy for Cordova:
https://leanpub.com/developingwithcordovacli/read#version-control
It didn't take me overnight to figure all this stuff out, in fact it took a little bit more than two months. I hope my answer can server as a guide to you and others to address your concerns you mentioned in your opening post.

I am using gruntjs, javascript, jade, bower, and phonegap to build hybrid web applications and phonegap mobile applications. After some investigation, I settled on to use jade template language for creating my html and javascript files. This is my setup.
//begin grunt module
module.exports = function(grunt) {
var $jadeConfigObject = {
compileDevelopment: {
options: {
pretty: true,
data: {
debug: true,
**phonegap : '<%= isPhonegapBuild %>'**
}
},
files: [{
expand: true,
cwd : "src",
src: "**/*.jade",
ext: ".html",
dest:"dist/development/www/"
}]
}
};
grunt.initConfig({
pkg: grunt.file.readJSON('package.json'),
clean: [$dist_folder,"www"],
jade: $jadeConfigObject
// other gruntjs tasks
})
grunt.registerTask('setPhonegap', 'Set Phonegap related values.', function(n) {
**grunt.config.set('isPhonegapBuild', true);**
});
grunt.registerTask('buildPhonegap', ['setPhonegap','buildDevelopment'
,'copy:phonegap_www']);
}
Now explanation
Use gruntjs setPhonegap task to distinguish between phonegap build and normal web application build.
Task setPhonegap set isPhonegapBuild config property, this property, in turn, is used by jade config object. Then I can use "if phonegap" statements in jade files.
I have following line in my jade layout file
include ../includes/mainJavascript.jade
mainJavascript.jade
if phonegap
script(type='text/javascript',src='#{mainFolder}/cordova.js')
script(type='text/javascript',src='#{mainFolder}/cordova_plugins.js')
script(type='text/javascript',src='#{mainFolder}/plugins/org.apache.cordova.device/www/device.js')
script(type='text/javascript',src='#{javascriptServicesFolder}/pushTokenService.js')
script(type='text/javascript',src='#{javascriptFolder}/plugins/com.phonegap.plugins.PushPlugin/www/PushNotification.js')
script(type='text/javascript',src='#{javascriptFolder}/phonegap/pushNotificationHelper.js')
This way I have following features
My web application does not contain any phonegap related scripts or html
I can use jade layouts (Master Page) to simplify my files very easily.
Adding new javascript to every page or changing every html for every page in application very easy.
Note that phonegap wants www folder for its build scripts, therefore I create following directory structure.
src -- every code file here, jade, javascript
www -- only created for phonegap build
dist/development/www -- normal development www build
dist/production/www -- production www build
I ignore www/* and dist/* in my source control. I only work with src jade and javascript files. Add this setup to bower, I believe it is a good option.

Related

VertX Webserver static content webroot

I've got two projects which I've created:
A web UI built using webpack
A Vert.x webserver written in java built using Gradle
I want to find a way to bring the resulting build dir contents of the first project into the second as the webroot which will be server up using the StaticHandler.
Is anyone aware of a clean way to do this? I want to preserve the two git projects as they are because I like using the webpack dev server for development of the UI and it generally feels cleaner to have them separated.
I was looking at potentially using the bitbucket pipelines build on my repo, however bringing the assets generated by the first project into the build of the second is where I'm facing issues.
You could create a gradle task that before that depends on the jar task (so it runs before it) executes webpack compile into the resources directory. So when your jar task runs it bundles the compiled webpack code.

Advice on integrating Closure Compiler to build process

We want to use Google Closure in our build process as follows:
when in development mode, include base.js and dynamically add script tags
when in production, use minification and all the other cools stuff
This is a Java project running on Tomcat and we are transitioning from Maven to Gradle, and have continuous integration set up using Jenkins. We use Apache Tiles as a frontend technology.
I came up with a possible solution, but I feel it painful and ugly, and would like to know if there are better (cleaner, simpler, etc...) solutions.
My stinky solution:
Use a Tomcat context parameter to identify production mode. In the JSP files, check for this variable and include Closure's base.js or the minified js file accordingly.
So... any other suggestions? Possibly with pros/cons?
I use Grunt for this. Grunt is a tool to automate frontend minification, compilation, unit testing, etc.
URL: http://gruntjs.com/getting-started
In Grunt, you create a Gruntfile and register a task that consists of one or more reusable configs. A config does something like: "minify all files in this directory and output to that file". So what you would do is register two tasks: one for dev and one for production, with some configs in common, and some configs specifically for that environment.
You can pass your Tomcat context parameter to Grunt as a parameter (cleanest), or alternatively read it as an environment variable inside the Gruntfile and create an if branch in the configuration.
Grunt has a lot of plugins: The plugins you need are already available:
Conditional including/excluding of files: native support
Generate script tags: https://github.com/Zolmeister/grunt-sails-linker
Google Closure Compiler: https://github.com/gmarty/grunt-closure-compiler or https://github.com/blaise-io/grunt-gcc-rest

dart, specify root folder for web

I want to have some example sites in my web framework package. The sites run ok if I just want to run them as dart only implementations, but if I want to compile them to javascript I currently copy the sub folder out from my packages /example directory and into a new packages folders /web directory, as I only know how to get dart build to compile the client side code to javascript if its in the web directory. Is there anyway of telling dart build to run in a different root folder? like pkgRoot/example/example_1?
pub build example works fine for me but not yet for Polymer projects (this is work in progress)
Polymer doesn't like when it has a transformer configuration in the package where elements are imported from.
I maintain two polymer elements packages (polymer_elements/polymer_ui_elements).
I have the example files in example but use another package (e.g. polymer_elements_examples) to build the examples to JavaScript.
This polymer_elements_examples has a pubspec.yaml file with a dependency to polymer_elements, a transformer configuration for the entry pages, and example as a symbolic link to polymer_elements_examples
I then build the examples in polymer_elements_examples with pub build example.

How can I manage client-side JavaScript dependencies? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Although there are great solutions to manage dependencies on the server side, I could not find any that satisfies all my needs to have a coherent client side JavaScript dependency management workflow. I want to satisfy these five requirements:
Manage my client-side dependencies in a format similar to npm's package.json or Bower's bower.json
It should have the flexibility to point to a Git repository or actual JavaScript files (either on web or locally) in my dependency.json file for lesser known libraries (npm let you point to Git repositories)
It should minify and namespace all libraries into a single file like Ender - that's the only JavaScript file I would need to put in my <script> tag in the client side
It should have out of box support for CoffeeScript like BoxJS4 (now dead)
In the browser, I should be able to use either require style:
var $ = require('jquery');
var _ = require('underscore');
Or better yet, do headjs style:
head.js(['jquery', 'underscore', 'mylib'], function($, _, mylib) {
// Executed when all libraries are loaded
});
If no one such single tool exists, what is the best combination of tools i.e. a tool-chain that I can combine using something like Volo (or Grunt)?
I have already researched all the tools I have linked to in here and they satisfy only up to three of my requirements at best individually.
So, please don't post again about these tools. I would only accept an answer that provides a single tool that satisfies all five of my requirements or if someone posts a concrete workflow/script/working example of a toolchain of multiple such tools that also satisfies all my requirements.
RequireJS does everything you need.
My answer to this question may help you.
Example:
Client app project hierarchy:
sampleapp
|___ main.js
|___ cs.js
|___ require.js
main.js is where you initialize your client application and configure RequireJS:
require.config({
baseUrl: "/sampleapp",
paths: {
jquery: "libs/jquery", // Local
underscore: "http://underscorejs.org/underscore-min.js", // Remote
backbone: "https://github.com/documentcloud/backbone/blob/master/backbone-min.js" // Remote on GitHub
},
shim: {
backbone: {
deps: ["underscore", "jquery"] // Backbone depends on jQuery and Underscore.js
}
}
});
require(["cs!someCoffeescriptFile", "jquery", "backbone", "underscore"], function (SomeCoffeescriptFile, $, Backbone, _) {
// Dependencies are loaded...
// Execute code
});
Dependencies will use the cs plugin when prepended by "cs!". The cs plugin compiles the CoffeeScript file.
When you go in production, you can precompile your whole project with r.js.
node ./node_modules/requirejs/bin/r.js -o buildclientconfig.js
Here are your requirements:
Manage my client side dependencies in a format similar to npm's
package.json or Bower's component.json file. Different but as good!
I should have the flexibility to point to a Git repository or the actual JavaScript files (either on web or locally) in my dependency.json file for lesser-known libraries (npm lets you point to Git repositories). Yes
It should minify and namespace all libraries into a single file like Ender. That's the only JavaScript file I would need to put in my script-tag on the client side. Yes with r.js.
It should have out of box support for CoffeeScript, like Box. Yes
In the browser I can use either require style or headjs. Yes
RequireJS is the one you are looking for, I believe.
As Guillaume86, I think Hem will get you the closest to where you want to be.
In Hem, dependencies are managed using a combination of npm and Hem. Use npm
to explicitly install all of your projects external dependencies. Use Hem to specify which dependencies (both external and local) should be stitched together for you client side operations.
I created a skeleton project of this, so you can see how this would work. You can see it at Client-side Hem.
Adding dependencies
Use npm to search for a specific dependency and then modify the package.json file to ensure that the dependency is tracked in the future. Then specify the
dependency for your application in slug.json.
For example, suppose you wanted to add the CoffeeScript dependency. Just use npm to install the dependency and save it to your package.json file:
npm --save install coffee-script
Manually edit the slug.json file. Add "coffee-script" to "dependencies".
Suppose you wanted to include your own module 'bloomfilters' and it wasn't in the npm registry. You could add it to your project in the following way:
npm --save install https://github.com/dsummersl/bloomfilters/tarball/master
Manually edit the slug.json file. Add "bloomfilters" to "dependencies".
Local modules
If you want to include your own CoffeeScript or JavaScript code, you can do so by adding those files to the app/ folder. Note that in order to expose your script via the 'require' method you must make it a CommonJS module. It is very simple—see the Hem documentation.
Local files
If you want to include non-CommonJS non 'require' code, you can also stitch that by referencing your custom JavaScript or CoffeeScript code via the 'libs' list in
file slug.json.
CSS
Hem will stitch together your CSS too, if you want. See the Hem documentation.
Building
Once you have your dependencies listed, you can use hem to stitch them all together.
# Make sure all dependencies are present:
npm install .
# Make public/application.js
hem build
# See your minified js in public/application.js
Notes
Hem was meant for the Spine.js project - but you don't have to use it for that. Ignore any documentation mentioning spine as you wish...
There is also Browserify.
supports the package.json format
uses npm underneath which can use a GitHub (or any Git) repository as a package source
minifies and concatenates all dependencies into a single file.
supports CoffeeScript if you include it in your dependencies
require style all the way.
supports source maps
I'm pretty sure Hem meets your requirements (I use a personal fork with additional compilers, Jade and Stylus. It's easy to customize to your needs). It uses npm to manage dependencies.
You might want to take a look at Yeoman, which uses several techniques to help you with your requirements.
Our workflow is comprised of three tools for improving your
productivity and satisfaction when building a web app: Yo (the
scaffolding tool), Grunt (the build tool) and Bower (for package
management).
Built-in support for CoffeeScript, Compass and more. It works with r.js (RequireJS), unit testing, etc.
As for your requirements:
Bower is used for dependency management
Bower can work with local files, git://, http:// and more
Built-in support for minification and concatenation (even for your images)
Built-in support to automatically compile CoffeeScript and Compass (with LiveReload)
As stated in the build process: if you're using AMD, I will pass those modules through r.js so you don't have to.
All features:
Lightning-fast scaffolding — Easily scaffold new projects with
customizable templates (e.g HTML5 Boilerplate, Twitter Bootstrap),
RequireJS and more.
Great build process — Not only do you get
minification and concatenation; I also optimize all your image files,
HTML, compile your CoffeeScript and Compass files, if you're using
AMD, I will pass those modules through r.js so you don't have to.
Automatically compile CoffeeScript & Compass — Our LiveReload watch
process automatically compiles source files and refreshes your browser
whenever a change is made so you don't have to.
Automatically lint your scripts — All your scripts are automatically run against JSHint to ensure they're following language best-practices.
Built-in preview server — No more having to fire up your own HTTP Server. My built-in
one can be fired with just one command.
Awesome Image Optimization — I optimize all your images using OptiPNG and JPEGTran so your users can spend less time downloading assets and more time using your app.
Killer package management — Need a dependency? It's just a keystroke
away. I allow you to easily search for new packages via the
command-line (e.g. bower search jquery), install them and keep them
updated without needing to open your browser.
PhantomJS Unit Testing — Easily run your unit tests in headless WebKit via PhantomJS. When
you create a new application, I also include some test scaffolding for
your app.
Bower may suit your needs (1). And (2) for the rest you have RequireJS.
From the README:
Bower is a package manager for the web. Bower lets you easily install assets such as images, CSS and JavaScript, and manages dependencies for you.
To install a package:
bower install jquery
bower install git://github.com/maccman/package-jquery.git
bower install http://code.jquery.com/jquery-1.7.2.js
bower install ./repos/jquery
I just came across inject.js
Some of the features, from the project site:
Inject (Apache Software License 2.0) is a revolutionary way to manage your dependencies in a Library Agnostic way. Some of its major features include:
CommonJS Compliance in the Browser (exports.*)
View the full CommonJS Support Matrix
Cross domain retrieval of files (via easyXDM)
localStorage (load a module once)
Look at the Jam package manager. Following is the description from its homepage
For front-end developers who crave maintainable assets, Jam is a package manager for JavaScript. Unlike other repositories, we put the browser first.
It seems a lot similar to npm in how it works.
Install the package like below:
jam install backbone
Keep the packages up-to-date by executing:
jam upgrade
jam upgrade {package}
Optimize packages for production
jam compile compiled.min.js
Jam dependencies can be added in package.json file.
For complete documentation, read the Jam documentation.
There are a couple of options:
Browserify which allows you to import modules
RequireJS addresses the same problem
One that seems to be in active development is JoinJS
Component might also be of interest. It does not manage dependencies per se, but it allows you to use chopped up versions of otherwise large libraries.
Here's a solution that takes a very different approach: package up all the modules into a JSON object and require modules by reading and executing the file content without additional requests.
Pure client-side demo implementation: http://strd6.github.io/editor/
https://github.com/STRd6/require/blob/master/main.coffee.md
STRd6/require depends on having a JSON package available at runtime. The require function is generated for that package. The package contains all the files your app could require. No further HTTP requests are made because the package bundles all dependencies. This is as close as one can get to the Node.js style require on the client.
The structure of the package is as follows:
entryPoint: "main"
distribution:
main:
content: "alert(\"It worked!\")"
...
dependencies:
<name>: <a package>
Unlike Node.js a package doesn't know its external name. It is up to the package including the dependency to name it. This provides complete encapsulation.
Given all that setup here's a function that loads a file from within a package:
loadModule = (pkg, path) ->
unless (file = pkg.distribution[path])
throw "Could not find file at #{path} in #{pkg.name}"
program = file.content
dirname = path.split(fileSeparator)[0...-1].join(fileSeparator)
module =
path: dirname
exports: {}
context =
require: generateRequireFn(pkg, module)
global: global
module: module
exports: module.exports
PACKAGE: pkg
__filename: path
__dirname: dirname
args = Object.keys(context)
values = args.map (name) -> context[name]
Function(args..., program).apply(module, values)
return module
This external context provides some variable that modules have access to.
A require function is exposed to modules so they may require other modules.
Additional properties such as a reference to the global object and some metadata are also exposed.
Finally we execute the program within the module and given context.
This answer will be most helpful to those who wish to have a synchronous Node.js style require statement in the browser and are not interested in remote script loading solutions.
I use Hem with npm, and I wanted to add some additional benefits that I think weren't covered so far.
Hem has a self-contained web server (Strata) so you can develop your code without even needing to recompile. I never use hem build unless I am publishing an application.
You don't need to use Spine.js to use Hem. You can use it to compile arbitrary CoffeeScript packages if you set up file slug.json correctly. Here's one of my packages that is auto-compiled with cakefile:
TurkServer
Speaking of the above, Hem allows you to link other dependencies on your local system in with an npm link and combines them seamlessly even when you are using the Strata server. In fact, you needn't even use the cake method above; you can just link directly to CoffeeScript from dependent projects.
Hem supports eco (embedded CoffeeScript) for views and Stylus for CSS, and compiles all that, along with your CoffeeScript code, into one JavaScript file and one CSS file.
Here's a basic list for getting set up with a Spine.js, Hem, and CoffeeScript application. Feel free to ignore the Spine.js parts. In fact, sometimes I use spine app to set up a directory structure for a non-Spine.js application, then edit file slug.json to change to a different compilation structure.
Install NPM: curl http://npmjs.org/install.sh | sh on a Unix-like system. I'll assume it's available from the command line.
Install Hem globally (npm install -g hem). Development has branched as of late, so you might want to get it straight out of GitHub, checkout a branch, and npm install -g . in that folder.
npm install -g spine.app will make spine available as a global command
spine app folder will make a Spine project called app in folder, generating the right directory structure and a bunch of skeleton files to get started.
cd to folder and edit file dependencies.json for the libraries you need. Add them to file slug.json, so that Hem knows where to find them as well.
Optional: npm link any of your local packages in development to folder node_modules, and you can add them to file slug.json for Hem (either an index.js file to include directly or an index.coffee file if you want hem to compile it.)
npm install . to download all the dependencies you just entered in.
If you take a look at the default spine configuration, there is a app/lib/setup.coffee where you require all the libraries you need from your dependencies. Examples:
# Spine.app had these as dependencies by default
require('json2ify')
require('es5-shimify')
require('jqueryify')
require('spine')
require('spine/lib/local')
require('spine/lib/ajax')
require('spine/lib/manager')
require('spine/lib/route')
# D3.js was installed via file 'dependencies.json'
require 'd3/d3.v2'
In file index.coffee, you just do require lib/setup and load the main controller for your application. In addition, you need to do require on any other classes in those other controllers. You can use spine controller something or spine model something to generate templates for controllers and models. A typical Spine controller looks like the following, using Node.js' require:
Spine = require('spine')
# Require other controllers
Payment = require('controllers/payment')
class Header extends Spine.Controller
constructor: ->
# Initialize the class
active: ->
super
#render()
render: ->
# Pull down some eco files
#html require('views/header')
# Makes this visible to other controllers
module.exports = Header
The default generated index.html file will usually be fine for loading your application, but modify as necessary. Per your requirements, it only pulls in one .js and one .css file, which you never need to modify.
Edit your stylus files as necessary in the css folder. It's a lot more flexible than CSS :)
From folder, run hem server to start a Hem server, and navigate to localhost:9294 to see your application (if you installed Hem globally). It has some hidden arguments, for example, --host 0.0.0.0 listens on all ports.
Build the rest of your application using proper MVC techniques, and use stylus for CSS and eco for views. Or don't use Spine at all, and Hem will still work great with CoffeeScript and npm. There are many examples of projects using both models.
One more thing: normally, hem server will update automatically as you update your code and save files, which makes it a cinch to debug. Running hem build will compile your application into two files, application.js, which is minified and application.css. If you run hem server after this, it will use those files and no longer update automatically. So don't hem build until you actually need a minified version of your application for deployment.
Additional references: Spine.js and Hem: Getting started
Check out Cartero if you are using Node.js or Express.js on the backend.
I'd suggest to check out the Dojo Toolkit which seems to meet most of your requirements. The one I'm not sure about is CoffeeScript.
Dojo works with modules written in the Asynchronous Module Definition (AMD) format. It has a build system with packages and you can aggregate them in one or several files (called layers). Apparently it accepts Git type repositories, and more details on the build system are on Creating Builds.
For the record, v1.9 beta is expected next month.
Dependency injection with asynchronous loading and Browserify will be another good choice, compares to RequireJS.
asynchronous-frontend-dependency-management-without-AMD
Another framework that satisfies all my criteria released recently is http://duojs.org/ (and it also supports treating other resources, like CSS, as dependencies).

Bundler for javascript, or how to source control external javascript files

I am in the process of converting an existing Rails 3.1 app I made for a client into a Backbone.js app with the Rails app only as a backend server extension. This is only a personal project of mine, to learn more about Backbone.js.
While setting up Backbone.js (using Backbone-on-Rails), I noticed I have some dependencies (like backbone-forms) that come from external sources and are frequently updated.
I've grown accustomed to using Bundler to manage my Ruby gems, but I haven't found anything similar for JavaScript files. I'm wondering if there is any way to do the same for Javascript (and possibly css) files.
Basically I can see three possibilities to solve this issue:
Simply write down all the sources for each JS file and check these sources from time to time to see what has changed.
Use some kind of existing "Bundler for Javascript" type of tool, I've been looking for something like this but have yet to find anything (good).
Since most of these JS files will be coming from Git anyway, use Git to get the files directly and use checkout to get the latest version from time to time.
I prefer the last option, but was hoping on some more input from other people who have gone this route or preferred some other way to tackle this issue (or is this even an issue?).
I figure the Git way seems easy, but I am not quite sure yet how I could make this work nicely with Rails 3.1 and Sprockets. I guess I'd try to checkout a single file using Git and have it be cloned in a directory that is accessible to Sprockets, but I haven't tried this yet.
Any thoughts?
You don't mention it in your alternatives, but ideally you should use something like Maven to manage your dependencies. Unfortunately, there are no public repositories for javascript files. This discussion lists some other options which might be of help to you: JQuery Availability on Maven Repositories
For now I've settled on using the Git solution combined with some guard-shell magic.
The steps I follow:
Create a dependencies directory somewhere on your local drive
Clone the repositories with javascript (or css) files you want to use in the app
Set up a custom guard-shell command to do the following:
group 'dependencies' do
guard 'shell' do
dependencies = '~/path/to/dependencies/'
watch(%r{backbone-forms/src/(backbone\-forms\.js)}) {|m| `cp #{dependencies + m[0]} vendor/assets/javascripts/#{m[1]}` }
end
end
Place the Guardfile at the root of the app directory
It takes some time to set things up, but after that, when you have the Guard running, and you pull changes into your dependencies, the required files are automatically copied to your application directory, which are then part of your repository.
It seems to work great, you need to do some work for each new file you want to include in the asset pipeline, but all that is required is cloning the repository in your dependencies directory and adding a single line to your Guardfile, for example for the backbone-form css:
watch(%r{backbone-forms/src/(backbone\-forms\.css)}) {|m| `cp #{dependencies + m[0]} vendor/assets/stylesheets/#{m[1]}` }
Also, the reason I added this Guard to a group is because I keep my dependencies outside the main application directory, which means guard normally doesn't check my dependencies directory. To make this work, I start up my main Guard processes using bundle exec guard -g main and use bundle exec guard -w ~/path/to/dependencies -g dependencies in a new terminal window/tab to specify the -w(atchdir).

Categories

Resources