I'm currently working on a large angular.js project. I use grunt to concat/uglify all of my files into one large target.js file, which I then include on my index page.
I've come to the realization that this makes it quite difficult to debug in the dev environment since the code is then all on one line and super ugly. I thought about setting up a second grunt task that leaves the files pretty and separate (see this answer: Alternate grunt.js tasks for dev/prod environments) but then I have the problem of having to include all of the files on the index page when in dev, but removing those references and referencing just the ugly concat target in production.
I'm hoping to find a solution that allows me to keep pretty code in dev and ugly concat code in prod using grunt. I considered just adding script tags on the fly when in dev, and then somehow removing them when I use the production task, but this seems like a headache that might not be necessary, as well as I don't know how I would determine what script tags need to be removed/replaced.
I'm not 100% sold on this approach, as I'm just beginning the project and want to get this right the first time, so if you have a suggestion that better handles this situation, I would be open to accepting that answer as well.
A solution is to use the grunt-usemin and grunt-contrib-concat . That way you can define a block of ressources (css / js) that will be concatenated only when you execute the usemin task.
For example :
index.html :
<!-- build:js js/app.js -->
<script src="js/app.js"></script>
<script src="js/controllers/thing-controller.js"></script>
<script src="js/models/thing-model.js"></script>
<script src="js/views/thing-view.js"></script>
<!-- endbuild -->
Gruntfile.js :
// simple build task
grunt.registerTask('build', [
'useminPrepare',
'concat:generated',
'usemin'
]);
That way, files will be concatenated only at build time, leave your index.html will all the single references untouched in DEV mode
For more details / example, see : https://github.com/yeoman/grunt-usemin
Related
I have an angularjs application, and there are a bunch of controllers, services and directives. Let me say they are controller.js, service.js and directive.js, but the truth is there are many more js files than three. To reduce the http request, I'm combining those js files into one, let me say it's app.js. So my index.html looks like
<html lang="en">
<body>
<div data-ng-view></div>
<script src="app.js"></script>
</body>
</html>
However, in my development environment, I want to debug separated files not the combined one. A modified index.html gives the capability.
<html lang="en">
<body>
<div data-ng-view></div>
<script src="controller.js"></script>
<script src="service.js"></script>
<script src="directive.js"></script>
</body>
</html>
However, I don't want to change the index.html. Is it possible to define something like:
require('controller.js');
require('service.js');
require('directive.js');
in my app.js. I've done some search, and the results show there's a way using angularjs and requirejs together, however, it needs me to re-define my controllers and services in requirejs way. It takes a lot of effort in my case. And, I don't need to implement the dynamically loading since in production environment, there's just one javascript file that needs to be downloaded.
A very nice solution is to use sourcemaps. so even though you have one file, the browser knows the initial file! Read more html5rocks.
Also I would strongly advise you to use a javascript task runner/build system for these kind of jobs, like grunt or gulp.
To concatenate and create the sourcemaps with gulp is as simple as:
var gulp = require('gulp');
var concat = require('gulp-concat');
var sourcemaps = require('gulp-sourcemaps');
gulp.task('javascript', function() {
return gulp.src('src/**/*.js')
.pipe(sourcemaps.init())
.pipe(concat('all.js'))
.pipe(sourcemaps.write())
.pipe(gulp.dest('dist'));
});
A second option is this plugin gulp-preprocess where you can set up different env variables let's say dev, production . And depending on the task load either the concatenated file or each one individually.
Sorry for providing solution based on external plugins but I think they can save you lots of time !
If you want to keep the files separate for testing and debugging, but combine them for production, I'd recommend a build system like Grunt.js or my personal favorite, Gulp.js. Using these automated build tools, you could have it create a task where it will create your project directory, combine, minify, and mangle the JS files and generate maps that allow dev tools to reference the original files. This can do wonders for your workflow. This does require Node.js, so you will have to install that as well. It's still a good amount of effort, but I'd think it would be better than rewriting all your code.
An example build file for your specific case might look like:
//this(my-js) will grab all js file in the js directory, combine, minify, mangle,
//rename and create sourcemaps. it also has a dependency(js-libs) to handle
//your libraries first.
gulp.task('my-js', ['js-libs'], function() {
return gulp.src([
'src/js/*.js',
])
.pipe(plumber())
.pipe(sourcemaps.init())
.pipe(concat('app.min.js'))
.pipe(uglify())
.pipe(sourcemaps.write('maps'))
.pipe(gulp.dest('build/js'));
});
//this task will run the js task and then start a task that watches the files for
//changes and reruns the my-js task anytime something changes
gulp.task('default', ['my-js'], function () {
gulp.watch('src/js/*.js', ['my-js']);
});
Now this is just an example I came up with off the top of my head. Untested. Once es6 comes out we'll have access to import 'somefile'. Also, keep in mind that when http/2 is fully implemented, we'll have multiplexing, which will allow for multiple file requests in a single connection: https://http2.github.io/faq/#why-is-http2-multiplexed
I need to:
Copy index.html to index.uncompressed.html
Change some the references in index.html from .js to .min.js (i.e. my_jsfile.js to my_jsfile.min.js)
3) Minify index.html
I am using Grunt.
Number 3 is no problem.
I assume number 1 will be easy.
For number 2, I was planning on using some sort of Grunt editing plugin and changing all .js file references between <!-- Start Here --> and <!-- End here --> from my_jsfile.js to my_jsfile.min.js.
Is this the way this type of thing is done?
The resource I use in this situation is grunt-processhtml, which will do exactly what you're looking for. Check out one of my repos, steady-backbone-boilerplate, where I use this to do exactly what you're describing.
In particular, I find this is a helpful example:
<!-- build:[src] js/source.min.js -->
<script data-main="js/main" src="js/vendor/require.js"></script>
<!-- /build -->
So, in development we're using the requirejs script to load all our dependencies. In our production index.html file, we're loading the source js file, which has been minified with the grunt-requirejs module.
I am using git (via GitHub) for version control on my projects. I'm still new to this but I'd like to know best practice for how to keep my css and js files synchronized between environments.
Example: Let's say I write a js script on dev. I'm happy with my work and I push to testing. Well on testing I would want a minified/compressed version. How would I accomplish that without a lot of overhead tasking? What do you guys do? I'm assuming it's part of some sort of deploy script that would compress the code and push it to whatever environment I specify.
This brings up another question: What about my header (and/or footer) file(s) in my project? If my dev has:
<link rel="stylesheet" href="<?php echo base_url(); ?>css/main.css">
and my testing has:
<link rel="stylesheet" href="<?php echo base_url(); ?>css/main.min.css">
That's all fine, but what if I need to make changes to my header? How would I separate all these things from each other? If I make changes to my header and push to testing or production I would lose the .min from that include line.
Currently what I do to deploy updates is just a simple git pull origin [branch] from the command line inside the environment I want to update.
Again, I'm looking for best practice, whatever learning it requires. Thanks!
You might want to check out preprocessor tools, such as LESS or Sass. These tools allow you to write CSS (I believe they may be able to handle JS, too, for purposes of minifying), and set up scripts that handle how they compile the code, based on the environment.
What you'd do, then, is write your code in "source" files, and set up the preprocesser to compile the code according to settings laid out in a settings file (for Sass, this is easily done with the Compass framework), based on the environment you're in. You'd then keep only the source files in the repository (set Git to ignore the compiled versions), and set up post-receive hooks to compile the source files on the server. Your HTML can then be written to access the compiled files (which should have the same name across environments), so you don't have to write logic that determines on the fly, every time, what environment the code is running in.
Don't put minified version of CSS, JS into version control. That's duplicate.
Git can be used on delopy but its purpose is not deploy.
For the including CSS tags, that's easy. A quick roundup is use your framework's env vairable. As I know CodeIgniter has this function. If env == test, include minified version, if not, include raw versions.
Besides you need a build script or framework plugin to generate minified versions automatically.
Typically a minified file is generated by your CMS on page load. So from a code standpoint you don't need to track the minified version as all the code is tracked in your actual js and css files. So minified copies can just be ignored using the .gitignore file.
My .gitignore file typically looks like:
css-min #directory to store generated minified css files
js-min #directory to store generated minified js files
tmp #directory to store temporary files
files/images/cache #directory for storing generated images such as thumbnails
settings.php #File that stores system variables.
The settings file is used to set global variables such as your platform like "dev", "staging", "production". Then in your other files you can check the platform as to which css/js files to use. Since that file is ignored by your repository you can make the settings specific to each platform.
if ($GLOBAL['platform'] = PLATFORM_DEV) {
$path = 'css/main.css';
}
elseif ($GLOBAL['platform'] = PLATFORM_STAGE) {
$path = 'css-min/main.min.css';
}
<link rel="stylesheet" href="<?php print base_url(); print $path; ?>">
I'm wondering if someone can check my understanding of what the intended purpose of HTML5Boilerplate js directories. I understand that main.js is where I'm expected to place all site specific javascript that I author. Plugins.js is where I would place all jQuery plugins used. Both main.js and plugins.js will be concatenated and minified by the build process. Vendor.js holds javascript libraries. This directory will be minified (unless it is already minified) but not concatenated.
If this is true, then my question is where should something like cute slider which has a modular structure be placed? I'm thinking I want it to be minified and concatenated so it shouldn't go in the vendor directory. I don't believe I can add cuteslider's javascript to main.js or plugins.js without destroying it's modular structure. Should I create a new directory, and call it something like apps, to hold cuteslider code and then modify the build code to minified and concatenated it?
Here is a snippet of cuteslider's code structure
cute
cute.2d.module.js
cute.canvas.module.js
cute.css3d.module.js
cute.gallery.plugin.js
cute.slider.js
cute.transitions.all.js
First you have to consider cuteslider as a plugin.
Add the required files to make the plugin working (cute.slider.js, cute.transitions.all.js and respond.min.js) in the plugins.js.
Then add the js to load the slider into your page in the main.js as
$(document).ready(function() {
// code here to load cuteslider
});
The modular look have to be set only in the main.js file.
I have a simple Dojo application, that does only one require call, loading all the dependencies. The trouble is, while it is extremely simple, it still ends up loading ~100 files from server. I tried to solve that problem using Dojo build system, but seems I don't have a deep enough understanding.
So my question is - given a list of dependencies, like the following:
["dojo/parser",
"dijit/registry",
"dojo/dom",
"dojo/on",
"dojo/query",
"dojo/dom-class",
"dojo/request",
"dijit/form/ValidationTextBox",
"dijit/form/Select",
"dijit/form/NumberSpinner",
"dijit/form/CheckBox",
"dijit/layout/ContentPane",
"dijit/Dialog",
"dojo/NodeList-traverse",
"dojo/domReady"]
how do I set up the build to create a single-file (or several-file, just not 100-file) dojo file?
If you're using Dojo's require() loader, there are build tools that you can use to combine files and minify. According to the site, the build tools aren't included in an official release, so you'll have to get them from the development version (specifically, look in the buildscripts directory).
The Dojo documentation contains some info on its build system that you may also find useful.
As a proof of concept, here are the steps I took:
Go to the download page, and download the Source Dojo Toolkit SDK (it's the only one that contains the util scripts needed for a build).
Extract to a location (for the sake of this post, let's say it's /opt/dojo-toolkit).
From the Dojo toolkit directory (i.e. /opt/dojo-toolkit), run the build util: ./util/buildscripts/build.sh action=release htmlFiles=/path/to/my/index.html (careful, this slowed my 5-year-old dual-core to a crawl)
Example of index.html (this one is exactly inside the dojo-toolkit directory):
...
<head>
<script src="dojo/dojo.js"></script>
<script>
dojo.require("my.test");
</script>
</head>
...
The require() call looks for nested modules (I couldn't get it to work with a top-level module), so in this case, I've got a my directory inside of dojo-toolkit which contains a test.js file. That file is the main "bootstrap" file which loads in all of the dependencies. I just put random require() calls in mine:
dojo.require('dijit.ProgressBar');
dojo.require('dijit.Tree');
And that should do it. Basically, running the build utility against your HTML file (the one that contains the reference to dojo.js) makes sure that all of the dependencies are found, starting from the top.
Note: the build system create a release directory with the built output, but it looks a little misleading at first - it appears to have minified each individual file, but if you look at your actual bootstrap file (my/test.js, in this case), it will be a combined, minified file with (I presume) everything you need to run your app.
Otherwise, if you're using AMD style require()'s (as in require.js), you can use its optimization tool. According to the site, it will:
Combine all dependent files (including require.js itself) into a single file. It analyzes the require() call to figure out which files it needs to combine.
Minify your JavaScript using either UglifyJS (default) or Closure Compiler.
I needed to do the same thing and this is how I solved it.
If you read the documentation about how to create custom builds (http://dojotoolkit.org/documentation/tutorials/1.8/build/), in the Layers section they talk about creating custom layers. You can add all the modules you need there. Here is an example of my custom layer file:
layers : {
"dojo/dojo" : {
include : [
"dojo/dojo",
"dojo/_base/window",//
"dojo/dom",//
"dojo/dom-class",//
"dojo/ready",//
"dojo/store/Memory"
],
customBase : true,
boot : true
}
}
What this will do is build only those modules into dojo.js, along with the bootstrap loader so that you can load other modules on the fly.