I have a NodeJS application with Express based structure and Jade module for a views. I need to use a full version my assets on a developer machine and min version in production machine.
Can you explain best practices of how should I do it properly?
EDIT: If you put a minus please describe the reason.
Not sure why there isn't an "official" way of doing this (compared to what Ruby on Rails does).
Here are a few suggestions:
DIY
Here's what I've been doing so far:
At server startup, I run uglify-js on all the js files (under .../js, and create the minified version under .../min) with something like so (leaving out the reading/writing of the files):
var jsp = require('uglify-js').parser;
var pro = require('uglify-js').uglify;
var ast = jsp.parse(code.toString('utf8')); // parse code and get the initial AST
ast = pro.ast_mangle(ast); // get a new AST with mangled names
ast = pro.ast_squeeze(ast); // get an AST with compression optimizations
var final_code = pro.gen_code(ast); // compressed code here
then in html templates, based on some environment variable to trigger production environment, I generate the path for the <script> tags to either point to .../js or .../min.
This leaves out quite a lot (where you would group all js files into one minimized one to reduce the number of browser queries and such), but hopefully this can help you craft your own strategy.
Piler
That said, I've been meaning to try piler (https://github.com/epeli/piler), which seems to be a better alternative to the DYI way.
Using Grunt
Grunt.js (http://gruntjs.com/) is also quite suitable to help preprocess files (html, js, css, ...)
Here are a few pointers:
grunt-recess: https://github.com/sindresorhus/grunt-recess (especially interesting if you use less)
how to config grunt.js to minify files separately
Grunt tasks to process HTML files and produce a deploy directory of optimized files (https://gist.github.com/necolas/3024891)
I view minification as a build step and prefer to not burden the application at runtime with it. Therefore, I would setup my HTML files to refer to file paths which are generated from the build tool and then use the build tool to figure out whether or not to minify.
I haven't actually needed to make it conditional myself because I haven't needed to have unminified code in the browser. With grunt setup to watch the source files and recompile automatically, I can edit a JavaScript source file and it automatically gets rebuilt and placed into the appropriate runtime location. However, I could see this being useful for stepping through code. IE 9 has a formatter in its dev console which is useful for debugging minified code, but I'm not sure how common that is across browsers.
If I were to skip minification in development, I would first check if I can make the grunt uglify task use a config setting like an environment variable or npm setting, etc. to decide whether to actually uglify or not. If that is not possible, I would make a separate grunt task called "devBuild" that does everything except uglify.
Related
I'm having a problem using Gulp to compile a RequireJS project properly. What I need to do is have gulp create a single distribution file that only includes the file necessary to have the application run.
In our application we are following a modular approach breaking out major pieces of functionality into different repos. So while developing my piece I have RequireJS including angular and many other vendor libraries that are common to all of the projects in the application. However when I go to move my piece into the larger application I no longer need these files in the final output since those dependencies also exist in that application (and having those extra libraries also makes the final distribution file over 300K).
I've tried creating another main.js (called gulp-main.js) file that only includes the dependencies that I need but when I run the gulp process it fails. I don't get an error but it seems to be failing because I'm not including the required dependencies for the project to build successfully. Below is the config object that is being passed to the RequireJS optimize method.
var config = {
baseUrl: 'app/',
mainConfigFile: 'app/main.js',
out: 'dist/app/output.js',
name: 'main'
};
Any ideas on what I could do to either remove the unnecessary vendor files or even split them into a single vendor and a single non-vendor file would really be appreciated. I have already tried using the modules array option but that does not produce the results that I am after since it seems to create a single file for each item defined not a single compiled JS file with all scripts contained within.
Thanks in advance.
When you don't want some file in your final output. add " ! " in Your gulp task's src
example :
gulp.src(['./app/*.js', '!./node_modules/**']) // '!./vendor-libraries-dest to igonore'
I've got a very crude implementation working:
var screens = {
a: require('./../react_components/screens/a.jsx'),
b: require('./../react_components/screens/b.jsx'),
c: require('./../react_components/screens/c.jsx'),
d: require('./../react_components/screens/d.jsx'),
e: require('./../react_components/screens/e.jsx')
};
Which works fine, however, I'd like to make it a little more scalable, so that when I change a filename, or add a new file to the /screens folder, I don't really have to keep updating this list of require statements.
I'm using Browserify, so I do have a build step I can hook into if need be (this will be ran in the browser)
So for node/commonjs itself there are modules such as requireindex that will automate this kind of thing. However, the fact that these approaches determine the dependencies at runtime by looking at the filesystem defeats browserify's static analysis so I'm not aware of any of them that are browserify-compatible. Therefore, I'd suggest a code generation route where you use a module such as glob to discover the files you want to export, but then write out a full .js file with the exports all statically coded, and point browserify at that file, which you can regenerate every time during your build step.
Problem: I don't want to send prefixfree.js to client each time, i think it may not be good for speed and can be solved at server side.
But at the same time i don't want server to redo the same work over and over again. I want serer to do this:
when server is started...
Convert less to css
make 4 versions of all css files:
webkit
moz
ie
all browsers
then serve them appropriately, so if browser agent is webkit, serve webkit version of that css file. and if can't be determined then serve the all version.
Now i could serve the all file instead, and i know it won't add that much to the size of file. But i don't know how to make less compiler output a prefixed version and i don't want to go each css file in command line and run some command to add prefixes. Also, isn't a good practice to try to improve the flow as much as possible.
I could also use some ide plugin to add prefixes in less file, but that makes css files huge and hard to debug.
To make the right decision you should find out which browsers you have to support. Yous should also consider Graceful degradation.
Personal i think running Less with the autoprefix and clean-css is a safe choice in most situations.
Testing is simple:
npm install less
npm install less-plugin-clean-css
npm install less-plugin-autoprefix
lessc source.less production.css --autoprefix --clean-css
Notice that you can set your target browsers as an argument for the autoprefix plugin. To support the same browsers as Bootstrap does use the following:
--autoprefix='Android 2.3','Android >= 4','Chrome >= 20','Firefox >= 24','iOS >= 6','Opera >= 12','Safari >= 6'
You are right. Vendor prefixes will make your CSS file larger. You should notice you can compress / minify your code (also zip) and you code can be cached by the browser.
You should compare the larger code with -prefix-fee; 2kb gziped an extra http process and some JavaScript processing. Vera explains why using it can be a good idea at: http://css-tricks.com/five-questions-with-lea-verou/
You idea is somewhere between the above two solutions. You css code is possible a little smaller, but you still will need some JavaScript processing to find out the browser of the user.
I could also use some ide plugin to add prefixes in less file, but that > makes css files huge and hard to debug.
You can use the autoprefix plugin together with CSS sourcemap for easy debugging (use the --source-map option of the Less compiler). In most situations you will have a develop and production version of your code.
As already made clear by #seven-phases-max you can integrate all the above in a build chain with Grunt or Gulp.
I'm using grunt concat/uglify to reduce the number of calls being made to load JavaScript.
I removed all the hard-coded links to the actual javascript files, and now reference the one javascript file produced by grunt.
how can I continue to debug/view my javascript in my development environment?
Is that what source maps are?
i.e.
https://www.npmjs.org/package/grunt-concat-sourcemap
Yes. You will need to generate a sourcemap to continue debugging your code easily.
There are two types of sourcemap, but the sourcemaps need to be maintained through each transition. SO if you concat in one step an minify in a second step, the minify process needs to know that the concat step generated a sourcemap and generate it's own sourcemap based on that sourcemap, so that the minified code sourcemap corresponds to the original input, not the input from the concat step.
There are several ways around this -- the easiest way is to just not minify in your test/deveopment environment. There are also minifiers that will do the sourcemapping correctly for you, but they can be hard to configure.
You might also want to take a look at browserify -- this is a tool that lets you write your front-end browser code like it was node modules, and it will concat and generate sourcemaps for you!
Alternatively you can also just rely on gzip compression from your server and run your code through a minifier -- this works surprisingly well.
I'm enjoying emberjs a lot and would like to take the next step in a couple of my small, mobile apps and precompile my Ember/Handlebars templates as part of my build process.
I'd prefer to stay away from messing with Ruby and would like to use node.js as I'm more comfortable with using it.
I believe what I want to use is Ember.Handlebars.precompile, but unfortunately I'm unable to load the canonical ember.js file in a node environment. Example of a naive attempt from the node repl:
> var e = require('./ember');
ReferenceError: window is not defined
at /Users/jeremyosborne/git/projects/ldls/client/lib/emberjs/src/ember.js:5:1
at Object.<anonymous> (/Users/jeremyosborne/git/projects/ldls/client/lib/emberjs/src/ember.js:1596:2)
--- stack trace, you get the idea ---
I think I've already figured out how to set them up in my code so that they work correctly with my views, I just want to compile them in an environment outside of a browser DOM.
In lieu of getting the canonical ember.js to load in node, are there a specific set of files that I can pluck from the ember repo and use to compile my templates?
EDIT
I did a kluge fix that works great but gets an F for maintainability. I grabbed all the Handlebars code minus the reference to the window object. Then I followed with the Ember.Handlebars.Compiler code, replacing Ember.create with Object.create, exporting my Ember object, and viola things work seemingly great in node (as in it works and the functions produced are templates). But I don't consider this an answer to my own question due to the aforementioned maintainafail, so still open for answers.
EDIT 2
The above turns out to be a total fail. Perhaps there's something wrong in the procedure, but using Ember.Handlebars.precompile or Ember.Handlebars.compile doesn't work. The templates get made, but when I use the precompiled templates attached to Ember.TEMPLATES in my code, they do not work. I only seem to be able to get templates to work when they are explicitly passed in the modified script tags, as suggested on the emberjs.com site.
EDIT 3
I figured out what I was doing wrong. My answer is below.
I've written a grunt plugin called grunt-ember-handlebars that does exactly this. It pretty much mimics Garth's script, with one important difference:
It uses lib/headless-ember.js and lib/ember.js, which are maintained (at least for now) by ember.js to precompile default templates. If you don't want to use grunt, you can extract the relevant code from the precompile_handlebars helper in tasks/ember-handlebars.js.
Found a good enough solution to my problem that seems easy enough to maintain that I'll consider my problem solved.
Here's how I solved things:
Grab the minimal amount of code I need to precompile the ember templates.
Copy the contents of the ember handlebars into a file. This file is located at the emberjs repo: https://github.com/emberjs/ember.js/blob/master/packages/handlebars/lib/main.js
Within the code, find the one instance of window.Handlebars = Handlebars; and remove it.
Append the contents of the Ember template compiler and handlebar overrides. The file is located at the emberjs repo: https://github.com/emberjs/ember.js/blob/master/packages/ember-handlebars/lib/ext.js
Find all instances of Ember.create and change to Object.create.
Outline of the simple precompile procedure:
Load up the code with a var Ember = require('./my_ember_precompiler').Ember.
Get your templates as strings and compile them with var templateString = Ember.Handlebars.precompile(str).toString().
This will be different from app to app, but Ember seems to require registration of precompiled templates. After loading, for every created template, we need to register our templates. Basically wrap templateString in a call to Handlebars.template() and make sure this wrapped function is added to the Ember.TEMPLATES object.
The above is painless when it's automated in a script.
I've published a version of ember-precompiler with a similar interface to the handlebars command line utility. You can install it from NPM:
npm install -g ember-precompile
and then run it as:
ember-precompile template... [-f OUTPUT_FILE]
It does essentially what you describe (and what the gist versions do too): mock out the missing components needed to run Ember and Handlebars, compile the templates and add them to Ember.TEMPLATES.
Take a look at the npm package Ember-Runner
The following gist contains a nodejs build script that will precompile all .handlebars files in a given folder:
https://gist.github.com/1622236
I wrote an official precompiler npm module for anyone else who might be wanting to do this w/ a recent version of ember.js
https://npmjs.org/package/ember-template-compiler
It's simple to install and use (example below)
npm install ember-template-compiler
var compiler = require('ember-template-compiler');
var template = fs.readFileSync('foo.handlebars').toString();
var input = compiler.precompile(template).toString();
var output = "Ember.TEMPLATES['foo'] = Ember.Handlebars.template(" + input + ");";
Look at the code for the official ember-rails gem at https://github.com/emberjs/ember-rails
While it's not a node.js project, it does show you how to precompile the templates using the Rails 3.1+ asset pipeline, and it includes all the necessary Javascript code that you would need to do it in Node without having to hack together a solution that you'd have to maintain on your own.
More specifically, look at vendor/assets/javascripts/ember-precompiler.js and lib/ember-rails/hjs_template.rb
I'm far from an expert on Node (obviously, Rails is more my thing).. but I think those two files should point you in the right direction. Basically, you're going to want to concatenate ember-precompiler.js (which acts as a "shim" for lack of a better word) with ember.js and then call EmberRails.precompile to compile your templates.
window object can be mocked by jsdom
var jsdom = require("jsdom").jsdom;
global.document = jsdom("<html><head></head><body></body></html>");
global.window = document.createWindow();
global.$ = global.jQuery = window.$ = window.jQuery = require("jquery");
global.Handlebars = window.Handlebars = require('handlebars');
global.Application = window.Application = {};
require('ember.js');
and now you can run anything from Ember including Ember.Handlebars.compile