I have several backbone.js views, javascript modules and style sheets in an ASP.Net MVC app i'm developing. I want to seperate these files during development but combine/consolidate, compress, uglify, resolve dependencies etc. before deployment. The Ruby community has solutions for this including Juicer and Jammit. Are there similar solutions for .Net web developers ideally solutions that integrate with visual studio.
I've used Chirpy for this in the past. Also compiles SASS, LESS, and CoffeeScript.
We use YUI Builder for exactly this purpose. (We also happen to use YUI extensively in our products.) It's Java/Ant based, but it wasn't hard to get msbuild to do all the work by creating a project file (csproj in our case) and overriding the "build" target. We include the project in our main .sln file, and it automatically builds along with all of our C#/.NET projects.
One thing to watch out for: We initially got frequent/random "access denied" errors when building this way. It turns out that Visual Studio was locking many of the intermediate files that YUI Builder generates. So our workaround is to robocopy all the relevant files to a temp folder, do the work there, and robocopy them back.
It's not ideal, and certainly not an out-of-the-box integration like you're probably hoping for, but it works well for us. It gives us minification, JSLint checking, dependency management, and an infrastructure for serving one combined file rather than individual scripts.
Related
We are planning to switch new technologies like react for my CMS project which is under development for 10 years.
Until now everything was simple and plain on the front end.
First include jquery.js then if necessary include the components and third party scripts, then code and dance with the DOM.
But now while trying to jump into a higher level of technology and different approach, things can easily get very complicated for me.
After spending more than 10 hours with React documents and tutorials I have a very good understanding about what it is and how it works.
But I realized that I am very unfamiliar with some popular concepts. I never used node.js, never used npm, babel, webpack, and may other many "new" things I have seen every where. I am face to face with these tools because of React and I am convinced that these are the inevitable for modern front end development.
Now the question
Our CMS runs on PHP and depends on MooTools heavily at the front end. Instead of a complete rewrite of a 10 years old CMS I just want to try new technologies partially for some cases. Decided to starting with React.
For the case I want to integrate ag-Grid to React also.
What I did not understand is that how to bring all these tools together.
I won't be able to use the simply include js way of react because of ag-Grid.
In the examples the code written has some JSX. Which means that we write JSX and run it translated for the browser to test if it is ok.
Each time before testing do I need to translate these files?
And more over if the files are translated does debugging become very
complicated?
Can babel make it on the run time? If yes is it a good practice.
There are lots of file in the node_modules folder. Which of them
should I include for production?
All sources on the net are very theoretical and assumes a knowledge. Need some guidance for best practices.
There are lots of questions and not a single step by step guide from beginning to production.
JSX is an extension over spec-compliant JavaScript. It is syntactic sugar for React.createElement(...) and is optional in React development.
React can be written in plain ES5:
React.createElement("div", { foo: "foo" });
Instead of JSX:
<div foo="foo" />
Or with helper functions like h that achieve the same goal, e.g. react-hyperscript.
The fact that there is PHP backend application doesn't prevent from developing React frontend application with JSX. This may require to configure React project to not use built-in Express web server and build client-side application to custom location, i.e. existing app's public folder. In case create-react-app is used, this may require to eject the project).
Each time before testing do I need to translate these files?
They should be transpiled to plain JavaScript (ES5 if it targets older browsers). They can be translated on every change in source files when client-side project runs in watch mode (conventionally npm start).
And more over if the files are translated does debugging become very
complicated?
This is what source maps are for.
Can babel make it on the run time? If yes is it a good practice.
It's possible to use Babel at runtime, and this isn't a good practice, even in development environment.
There are lots of file in the node_modules folder. Which of them
should I include for production?
The contents of node_modules doesn't matter. Almost all of them are development dependencies that are needed to build client-side app. This is the task for a bundler, which is Webpack in create-react-app template. It builds project dependencies to plain JS in dist folder.
I'm trying to get into Grunt, which I am new to, but I do not understand its utility.
I understand that it is a taskrunner. I understand that it can be used to do things like bundle, uglify, jshint, minify, etc etc etc, anything that can be turned into a scripted task.
But I don't see what advantage this gives. Nearly all of these can be run from the command line anyway, which is to say you could just combine them using a simple shell script. It seems to me that setting up grunt + gruntfiles and writing tasks is more work than writing a shell script, rather than less.
What am I missing about this?
Grunt is basically a build / task manager written on top of NodeJS. I would call it the NodeJS stack equivalent of ANT for Java. Here are some common scenarios you would want to use grunt under:
You have a project with javascript files requiring minification, and generally generating a front end build seperately (in case you're using say JAVA for your backend). (grunt-contrib-uglify)
When you save code on your machine during development, you want the browser to reload your page automatically (might seem like a small thing, but believe me this has saved me lots of time). (Live reload)
When a developer saves code on his machine, he wants a comprehensive list of JS errors / general best practice violations to be shown. (grunt-contrib-jshint)
You have a project with SASS/ LESS files which need to be compiled to CSS files on the developers machine during development, For example whenever he saves a SASS file, you want it to be compiled to a CSS file automatically, for inclusion in your page. (grunt-contrib-sass)
You have a team of front end developers who're working on the UI, and a team of backend developers working on the backend, you want the front end devs to use the backend REST API's without having to compile & deploy code everytime on their own machines. In case you were wondering, this isn't possible with a typical web server setup because XHR isn't allowed to be cross-domain by browser. Grunt can setup a proxy for you redirecting XHR requests on your own system within the grunt connect server to another system! (grunt-contrib-proxy, grunt-contrib-connect)
I do not think your shell script can do ALL of these. To summarize, yes, setting up a Gruntfile.js is tedious for someone who has had little exposure to javascript / is new to nodeJS, I went through the same pains as a learner, but Grunt is an amazing piece of software. DO invest the time to setup a proper Gruntfile.js for your front end project, and you'll thank god for making your life a lot easier :)
The Advantage vs shell script:
If you write shell script for every one of these tasks, it is tedious to maintain and then customize for every one of your needs. Gruntfile.js is actually pretty easy. there is a config that you init it with, specifying what tasks you want to perform, the sources and targets for each.
The integration with project seed generators on Yeoman, Gulp is another major factor to consider. Yeoman and Gulp come with Gruntfile.js' with intelligent defaults. For someone who is the sole UI contributor on his team, this is priceless to me!
For someone who is working on frontend technologies, if you have more than one person working with you, its rather easy for them to get to know Grunt, which is already well documented with a lot of answers on SO, than to get to know your shell scripts. This might be a factor in large teams.
The numerous plugins for Grunt extend base functionality. Unless your shell script is VERY popular, and VERY modular, I dont see plugins being built for it. This also extends to inclusion of new front end technologies in your project. Say, if you want to use typescript in your project tomorrow, your shell script will need to incorporate this and account for it with your own effort. With Grunt, its just as simple as "npm install " and adding a config.
Even though I agree with most advantages pointed in Accepted Answer, I still have to consider the disadvantages that are highlighted by Keith Cirkel in Why we should stop using Grunt & Gulp
Thus, some advantages are rebut by Grunt overheads and at least you should consider all this in your final decision of using Grunt, or not.
I have a java webapp project under eclipse that is using maven for dependency management.
This webapp also depends on many javascript libraries for the front-end, either provided by external "vendors" such as jquery or bootstrap, or developped "internally" by myself.
What I want to do is manage the javascript dependencies just as I would with java dependecies, inside my POM.xml.
Now, for external dependencies I would like them to be automatically downloaded from a repository ( either hosted by me or external) - this is what Webjars could provide I believe.
For my "internal" javascript libraries I would like to create them as separate eclipse projects, in my eclipse workspace, that would be referenced inside my webapp's POM the same way I would do with a secondary java project residing in my eclipse workspace.
I also want the referenced js dependencies to be properly placed under my /src/main/webapp/js/ folder when the webapp is deployed.
Finally, when modifying something in one of my "internal" javascript libraries, I would like the changes to be automatically deployed to the webapp, as if it was a regular java sub-project referenced in the main webapp project. I specially want the changes to be redeployed to the webapp if it is running / being debugged, under eclipse.
I have heard of Javascript maven tools : http://javascript-maven.softec.lu/
or http://mojo.codehaus.org/javascript-maven-tools/javascript-maven-plugin/
but thes plugins dont seem to be maintained anymore, are lightly documented, and I failed achieving the above requirements with them (probably because of the lack of concrete examples).
Now I know I'm asking for alot but I dont mind trying different approaches, and fooling around with different tools.
Any help, thoughts, insights etc ... appreciated
Thanks
I'd like to start bundling our javascript files. I've found that it's really easy locally using the web essentials plugin, however I need to set up the build server to generate the bundled .js file.
I'd rather not check this generated file into TFS as it will cause conflicts for our developers, and also since it's generated from the source I feel that the server build should generate it.
Is there a command line utility for doing the script bundling outside of visual studio that could be used as part of a build script? My google-fu is failing to find one.
Many thanks,
As long as you wrote it as proper AMD modules, require.js comes with a tool to turn all your files into an optimized bundle.
I have many JS snippets and files shared across multiple projects. I have to either copy-past them into a single file for each project, or serve them as individual files on cdn. Both are bad ideas.
Is there any dependency management and build tool like Maven for JavaScript? Ideally it would take a set of js dependencies and build a single js file which can be served on cdn.
I can write a script to do that. But I'm looking to find if anything comparable to Maven exists for JS.
Update 2014: Based on answers here and my research following are most popular tools:
Bower, NPM, RequireJS, Browserify, Webpack, Grunt, Gulp
There's RequireJS, but that's kind of a different thing than Maven, and what you're asking it to do is different than Maven too. There are any number of JS combiner/minifiers, like jekyll-combiner and a zillion others.
If you're using Maven, the JavaScript Maven Tools might be of interest. If you're not, I don't know of a unified way to specifiy, download, combine, etc. for arbitrary build systems. Some of the node.js stuff might be useful, but I've never used that outside of a node.js context, so I'm not sure.
http://webjars.org/ packages JS libraries as JAR files and makes them available under Maven.
RequireJS is not a replacement to WebJars; it complements it.RequireJS will use public JS files (on CDNs) at runtime, whereas Webjars will download the necessary files at build-time and have you host them yourself.
Because most JS files are not hosted on CDNs, I use Webjars to download the necessary JS files at build-time, and reference them using RequireJS. That way I get the best of both worlds.
Take a look to grunt. It's very flexible build tool for javascript projects. Used by jquery team and other big projects. It combine, minify, test, lint js files, wtitten in javascript, have dozens plugins for whatever you want