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.
Related
I am writing code for webtask.io and it seems as if I can only upload one file to run. I would like to organize my code into multiple files with different modules but then have them be compiled into one for upload. I have tried gulp with gulp-concat but this just concatenates the files without preserving any execution logic. I would assume there is a simple way to do this.
Webpack works well, especially with the webpack-node-externals' package: https://www.npmjs.com/package/webpack-node-externals.
Just set the --bundle argument.
$ wt create index.js --bundle
I am using Google Closure compiler to concatenate and minify files. I am using require and my module depends on some JS files. Part of the JS files belong to an internal JS framework and several others depend on modules which our team has written. My aim is to concatenate all the dependencies in 1 file and then minimize it. Following is the code (the files prefixed with 'oj' are the framework files)
define(['ojs/ojcore',
'knockout',
'jquery',
'generalApp',
'modules/helpers',
'modules/facade/mrd',
'modules/facade/trf',
'modules/facade/crf',
'modules/models/sm',
'modules/models/mm',
'modules/list/dls',
'modules/utils/cm',
'ojs/ojchart',
'ojs/ojmasonrylayout',
'ojs/ojmenu',
'ojs/ojbutton',
'ojs/ojfilmstrip',
'ojs/ojarraytabledatasource',
'ojs/ojselectcombobox',
'ojs/ojdialog',
'ojs/ojcheckboxset',
'ojs/ojpagingcontrol'
], function (oj, ko, $, app, helpers, mrf, trf,crf, sm, mm, dls, cm) {
});
These files are in-turn dependent on other JS files and I only want the dependent JS files to get concatenated in the final JS file. Any idea how to do the concatenation using the Google Closure Compiler?
I tried using --process_common_js_modules --transform_amd_modules flags but the compiler threw errors since its unable to find the framework files which are located under ojs. There is a requirejs configuration file in which we are declaring path variables but I dont know how to specify the config file during the concatenation process.
Thanks in advance
Closure-compiler does not know how to order dependencies natively with AMD modules. Instead, use the requirejs compiler to concatenate the files in the correct order and then use closure-compiler for minification. This is done by setting the requirejs optimize flag to none.
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 require.js's build tool (through grunt-contrib-requirejs) to pack up all my code into a minified version, and I've turned on generateSourceMaps.
However, the sourcemaps require is generating are wrong. In some files, they're fine, in others they're off by a line or two; in some, they're off by as many as 17 lines. What could be going wrong?
Possibly weird things about my repo:
handlebars templates integrated into the build (they're precompiled, using Alex Sexton's plugin)
a number of shimmed files that don't include require code standard (cordova, backbone, marionette).
I am using r.js to concatenate files, but not to minify them. Minifying the files doesn't fix the problem (the same line errors occur).
in some configurations, r.js gives an error that says it cannot generate source maps if preserveLicenseComments is on. In others (when not minifying), it seems to have no problem keeping license comments. Either way, turning it off does not help correct the line numbers.
files that are listed later in the sourcemap header seem to have larger errors
What could be causing this, and how can I fix it?
UPDATE
I've narrowed this down some: the sourcemap generator is losing a line every time it hits a line like this:
console.log('l170'); // logs as on line 170
//>>excludeStart('excludeHbsParser', pragmas.excludeHbsParser)
console.log('l172'); // logs as on line 171
I'm not precisely sure what the r.js parser is doing with these lines, but it does not seem to be accounting for them properly in the sourcemap generation.
Adding to r.js config:
skipPragmas:true
Did the trick for me, not sure if this will help everyone.
https://github.com/requirejs/r.js/blob/2.2.0/build/example.build.js#L299
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.