In my opinion, webpack-loader has the same function as babel-plugin！！
So can you help me answer the difference between the two, isn't it all through the AST to manipulate the code?
Babel: will turn your ES6+ code into ES5 friendly code, so you can start using it right now without waiting for browser support;
Webpack: A bundler for javascript and friends Packs many modules into a few bundled assets. Code Splitting allows to load parts for the application on demand. Through "loaders" modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ..., and your custom stuff.
Simply put, Webpack is a tool for putting your code through the processing pipeline and bundling it together into a single JavaScript file.
Babel can be classified as a tool in the "JavaScript Compilers" category, while Webpack is grouped under "JS Build Tools / JS Task Runners"
For More clarification see this answer Webpack loaders vs plugins; what's the difference?
Also check out this Medium post Webpack explained simply
Related
I am learning the typescript also I am learning how to implement typescript in Node.js. Now, I have watched several videos and in those videos I found 2 methods to tie typescript with Node.js.
One is by using decorators and other is by using the generic method type(by defining request and response types - Usage of interfaces.)
The question is -> Which approach is preferable and which to use.(I am aware that there is no good or bad way I but still want to know the answer) In addition to performance, I also want to know which approach is easier for others to understand because in my opinion, both are quite difficult to understand.
Or is there any other and easier way to implement typescript with Node.JS?
There are some tools to help run TS in NodeJS, such as ts-node (https://www.npmjs.com/package/ts-node), but if you don't want to rely on that or, like me, can't figure out how to get it to work, you will want to have TS do what TS does, and transpile it to JS. Then in package.json, you'll want to have your start script reference the initial .js file.
To transpile TypeScript, simply use the command tsc if you have a tsconfig, or tsc [starting file] if you do not. This should compile the code first, and if compilation is successful, it will then transpile to JS in the designated folder.
In your package.json, ensure the command executed refers to the output folder's initial file. For example: "start": "node dist/app"
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.
Due to the lack of support of modules or packages under development in npm I have decided to use webpack's components which from the look of the example provided here webpack/examples/components seems to be exactly what I am looking for. However there is no example how to actually use the example. Drawing from webpack's convention I thought that:
webpack/examples/components> webpack component.json > bundle.js
would do the trick but nope I get an error. Tried some other stuff like putting an entry file and an output file in the webpack.config.js but no luck there either. Has someone ever use it, does it work and most importantly how to start it?
I am creating my first Bower component. After running bower init the script asks me 'what types of modules does this package expose?' with these options:
amd
es6
globals
node
what is the difference between these options?
If you don't know, it's quite likely globals is the right answer for you.
Either way, you need to understand:
what is and why AMD
what is a nodejs module
what is ecmascript 6 and especially es6 modules
[UPDATE]
This feature was introduced very recently in bower and is not documented at all yet (AFAIK). It essentially describes the moduleType, which states for what module technology the package is meant to be consumed (see above).
Right now, It doesn't have any effect apart from setting the moduleType property in the bower.json file of the package.
See https://github.com/bower/bower/pull/934 for the original pull-request.
[UPDATE #2]
A few additional points, to answer comments:
right now AFAIK there is no validation done on the moduleType property - which means that people are technically allowed to use whatever value they want for it, including angularjs if they feel inclined to do so
the bower committee seems to not be keen toward the inclusion of additional non-interoperable/proprietary moduleTypes (think composer, angular, etc) - which is easily understandable, but yet again, nothing really prevents people from using the moduleType value they want
an exception to the previous is the (somewhat) recent inclusion of the yui moduleType, so, there are "exceptions" to be made, assuming they are part of a concerted plan
What I would do if I were to author a package for a not-listed package manager and publish it on bower?
I would author an es6 module, and use / patch es6-transpiler to output the package format I need. Then I would either/and:
petition the bower guys to include my package technology as a choice (based on the fact it's supported by es6-transpiler as a target)
publish my package including both the es6 module version of it and the transpiled XXX version of it, and use es6 as a moduleType
Disclaimer: I don't have real-life experience authoring angularjs modules.
Initial
I'm using bower init for first time too.
The options should refer to the different ways to modularize some JavaScript code:
amd: using AMD define, like requirejs.
node: using Node.js require.
globals: using JavaScript module pattern to expose a global variable (like window.JQuery).
es6: using upcoming EcmaScript6 module feature.
In my case I wrote a Node.js module dflow but I'm using browserify to create a dist/dflow.js file that exports a global dflow var: so I selected globals.
Other Updates
The command I used to browserify dflow as a window global object was
browserify -s dflow -e index.js -o dist/dflow.js
I changed it cause I prefer to use require also inside the browser, so now I am using
browserify -r ./index.js:dflow -o dist/dflow.js
and so I changed the bower.moduleType to node in my bower.json file.
The main motivation was that if my module name has a dash, for example my project flow-view, I need to camelize the global name in flowView.
This new approach has two other benefits:
Node and browser interface are the same. Using require on both client side and server side, let me write only once the code examples, and reuse them easily on both contexts.
I use npm scripts and so, I can take advantage of ${npm_package_name} variable and write once the script I use to browserify.
This is another topic, but, it is really worth that you consider how it is useful the latter benefit: let me share the npm.scripts.browserify attribute I use in my package.json
"browserify": "browserify -r ./index.js:${npm_package_name} -o dist/${npm_package_name}.js"
Just for reference, this is precisely what bower specifies regarding the module types:
The type of module defined in the main JavaScript file. Can be one or an array of the following strings:
globals: JavaScript module that adds to global namespace, using window.namespace or this.namespace syntax
amd: JavaScript module compatible with AMD, like RequireJS, using define() syntax
node: JavaScript module compatible with node and CommonJS using module.exports syntax
es6: JavaScript module compatible with ECMAScript 6 modules, using export and import syntax
yui: JavaScript module compatible with YUI Modules, using YUI.add() syntax
Relevant link: https://github.com/bower/spec/blob/master/json.md#moduletype
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.