For CSS, I can use SASS to import one CSS file to another and produce only single CSS file. What is the similar method for Javascript files?
You might want to check out Closure Compiler (which is a Google product).
You would probably want the Closure Compiler Application form of the product.
A sample workflow would probably look like:
Create a list of your JS files and paths
Run the command to compile and concatenate files (java --jar compiler.js --js path_to_file1.js --js path_to_file2.js (etc.) compiled.js)
Closure Compiler also has a related project, Closure Stylesheets, that does the same thing for stylesheets.
This approach, of course means that there's a pre-compilation step. Depending on your backend, there also exist libraries that do the compilation when the page is built. For example, for JSP, there's Granule a tag library that creates the compiled JS and CSS files at page build.
There's a third possibility: modularization. Since you gave the example of being able to import CSS files in SASS, an analogue for JavaScript is using a module library, using either the CommonJS standard, or (the one I prefer), the AMD (asynchronous module definition) pattern, which I have personally used with RequireJS. RequireJS also comes with a nice optimizing tool that will bundle up (minify, compress, concat etc) all the required files for your application
UPDATE
Since you mentioned that you are using Django in the comments (might be useful to update the question with this info too), see if this answer helps too
You could use minify which allows you to minify and combine javascript files. It also works with CSS.
Related
I want to add Flow to my current project I am working on. Everything works really great. However, I couldn't find a way of someway keep the types post build. I am using a monorepo structure and I have a lot of NPM modules. I would like to get an error if a module changes it's interface or it's exported functions/classes/types changes.
Any ideas/guidance is highly welcomed!
Thanks!
Webpack bundles JS files into a single output file, it has no way do preserve Flow types in the output bundle.
If you want to preserve Flow logic for use alongside this bundle, the current best practice would be to include your original sourcecode as .js.flow files. This blog post elaborates on this approach, but the short version is, you'd use flow-copy-source to output a bunch of .js.flow files that match your original source code.
If you insist on others including your compiled bundle instead of the source files, you'll need to include a .js.flow file that provides all of the external type interfaces. Here's the interface file for Immutable.js as an example.
Unless your library has some sort of build complexity that requires the distribution of its compiled assets, I would just rely on the consumers of your lib to compile and strip types on their own.
I have a large project entirely built in JavaScript, I have an ordered and "inside modularized" 5k lines .js file that's the engine of whole site.
Now I have to make other site (extension of this one) in which I'll have to repeat a lot of code, my question is, I've seen lot of possibilities using Browserify, CommonJS, etc. But that's not what I'm searching, I'm searching modularize JavaScript just like C/C++, making #includes with the files of the functions or functionalities and reuse code like that. I'm already doing this including other JS files in HTML, but that JS files are only variables and some arrays, not functionality of the site.
I use jQuery too, in that large 5k lines .js file I have almost all inside the jQuery document.ready event, that's bringing trouble too, because I'll have to make a document.ready event for every file?
I need some orientation please
CommonJS will let you require() modules, this is the foundation for the NodeJS module system. Browserify simplifies this implementation for use in browsers and even allows you to require Node modules (as long as they don't depend on binaries, the file system and other features a browser doesn't support).
var lib = require('someLibrary');
ECMAScript6 (aka: ES6) brings imports to javascript. While browsers don't fully support ES6 yet, you can use Babel to "transpile" ES6 to ES5. This ES5 will take advantage of CommonJS to replicate the importing behaviour.
import { SomeClass, someFunction, someValue } from 'some/library';
In all cases, your javascript will require some kind of pre-processing to transpile it into javscript a browser can understand. This usually means taking all your separate source files and bundling them into a single minified bundle file. This reduces the number of requests the browser has to make.
To handle all this transpiling and bundling, several popular build systems exist including Grunt, Gulp and Webpack. Grunt is older and typically slower because of it's configuration-based design. Gulp is simpler and faster because it relies on NodeJS streams. Webpack is the newest and most powerful, but at the cost of complexity. For what you're hoping to do, I'd recommend looking at Webpack since it can modularize not only your javascript but your stylesheets and other web assets.
http://webpack.github.io/docs/tutorials/getting-started/
Use webpack to bundle your code http://webpack.github.io/docs/tutorials/getting-started/
Haxe's JavaScript exports everything in a Haxe compilation into a single output file. This is great for building applications. For a general purpose library, however, it would be nice if it output a *.js file per *.hx file within my compiled sources.
The intent of this is so that I can create a NodeJs module where the consumer of the library only needs to require() the particular files that they would like to use. Is this currently possible using the Haxe compiler on its own, or via an external tool?
There is the hxgenjs library that can generate one js file per haxe class/enum.
https://github.com/kevinresol/hxgenjs
I see 2 different questions here
How to output Haxe module as a NodeJS module?
How to build each JS file into separated output file?
As for #1 there is #:expose directive and it should help.
As for #2 you can use --each and --next in your build *.hxml file. This way you can specify several targets at once(and they will be built at once too). Unfortunately there is no way to use the mask so you will have to list all your entry points(modules' roots) manually.
I see jQuery uses AMD in its sources. However in their concatenated dist file all AMD references are gone. How do they build their script, getting rid of the AMD and still keeping the source code functional?
Its using the requirejs optimizer (aka r.js) along with lots of customizations, including several regular expressions. Studying the source of the "build" grunt task will provide many more details.
I am trying out require.js and only include on js file at my main page. That main.js loads loads other scripts.
I am testing the performance of my site with yslow. It says that my page has 15 js files and I should try combining them into one. Isn't this the the purpose of require.js? That I shouldn't have to combine all my js into one large file?
Well, the idea of RequireJS is to build your scripts into modules (small parts). While doing that, you will notice that you are going to be dealing with many modules and thus many files.
To solve the "many files" problem, RequireJS has an optimizer.
RequireJS has an optimization tool that does the following
Combines related scripts together into build layers and minifies them via UglifyJS (the default) or Closure Compiler (an option when using Java).
Optimizes CSS by inlining CSS files referenced by #import and removing comments.