Client side app workflow - backbone.js
I'm trying to set up a client-side app workflow with yeoman (http://yeoman.io/), and as I'm coming from Rails background, I'm used to the niceties of the asset pipeline, which is backed by Sprockets (https://github.com/sstephenson/sprockets).
I'm struggling to make all the parts play nice with each other, and already spent a few hours trying to figure it out.
The first question that comes to mind is, is there a well established (e.g. convention over configuration, like in Rails world) way of developing a client side application with yeoman? Some definitive guide (besides the basic webapp-generator guide), perhaps?
Some suggest using requirejs (which I rather not use, because while it simplifies things in development, I'll need to jump through hoops to package the app (e.g. use Almond.js or AMDclean.js, or incur the unneeded overhead of requirejs).
My setup is:
Coffeescript, Backbone + Marionette, Handlebars for templates and ZURB Foundation with SASS.
What I'd like to accomplish in the end is the following setup, while using bower for managing the 3rd party dependencies:
In development:
Have something like Rails' manifest for javascript, so I can declare the order of dependencies, which will exploded into the the index.html
For all .scss files a .css entry added to index.html
Each file watched and compiled when needed
In production (dist):
All .scss files compiled, minified and concatenated to app.css
All bower files concatenated and minified to vendor.js
All application coffeescript files compiled, minified and concatenated to app.js
All templates compiled, minified and and concatenated to templates.js
index.html modified to include only those four files.
Is there something like this setup available?
I'm also open for suggestions and/or other alternative workflows.
Yeomam won't get you as close to a Rails workflow as you might expect. My two cents is that you take a look at something like Middleman has it does what you want out of the box.
Yeoman way
Using generators
You can use Yeoman generators and try to find out the combination of generators that will better suit the stack you are looking for, from what you describe I might take a look at:
webapp
backbone
maryo
At this point most of your requirements (both development and production) would be fulfilled:
a well defined project structure
compile coffeeScript and .scss
watch and compile
generators for model, view, collection, ...
compile and minify all files for production
You can use multiple generators to customise your own stack, every time that Yeoman detects that a generator overwrites a existing file it will prompt what to do, and you should be able to manage the conflict by yourself. Some framework-generators will obviously clash (it wouldn't make sense to try to use a angular generator on top of backbone).
Fine tuning
You can use sub-generators to scaffold more specific parts of your app, see Addy Osmani video.
Building generators
If you feel limited by some of the choices that a generator might impose (e.g. you prefer browserify instead of requirejs) you might want to fork a generator and add that as an option. You can even build a generator form scratch that will build your custom stack!
Grunt and Bower way
Yeoman is build on top of this two, but you can opt out at any moment and build your own stack using this two. You can add your dependencies through bower, and your tasks using grunt. There are plenty of examples that can give you some guidance, you could start with Yeoman webapp. There are also good examples at github like juanghurtado/puppeteer.
There are 3 files that you must keep an eye:
package.json — all you node dependencies go in here
bower.json — to manage the client dependencies
Gruntfile.js — here you define the tasks
Wrapping up
Maybe I'm stating the obvious but Yeoman does some magic work and helps you managing Grunt and bower, this magic only happens when you fully understand how this 2 work. So I would recommend that first you dive into some code and fully understand how Grunt and Bower work, and then you may use Yeoman magic.
Some other tools
You asked for some suggestions, here it goes:
gulp.js An alternative to Grunt. More you dive into Grunt more you will want Gulp (IMHO).
browserify An alternative to Requiere. Read this
assemble Static site generator for Node.js, Grunt.js, and Yeoman
Roman,
Answer for your first question, here is a guide on how to use Yeoman: http://code.tutsplus.com/tutorials/building-apps-with-the-yeoman-workflow--net-33254
If you want to use coffeescript by default, just pass the --coffee param
yo webapp --coffee
handling the assets order you can handle from the index.html file.
When you want to get the app ready for production just type the
grunt build
that will unify and minify all of your assets and throw it all dist folder.
To customise what you have in the build process you would have to write your own or customise the grunt build task, so that it will do exactly what you want.
Hope i gave you some useful information :)
Not an answer to my original question, but rather a pointer for someone who'd like to implement the same workflow I was looking for. I ended up writing a custom Gruntfile, using the grunt-injector to do the "explode the assets to the index.html" part, grunt-bower-install to add bower assets and configuring the grunt-usemin, grunt-contrib-concat, grunt-contrib-cssmin and grunt-contrib-uglify accordingly.
Related
Module parse fail: Babel parsing js module in React Project
I'm building my first semi-major MERN app with Redux, without a tutorial. It's really challenging, but a ton of fun. The project I am building is, essentially, a simple re-engineering of Zillow's API (they have a few, I'm after the more basic of the property search results). I am using the zillow npm module and want to add what appears to be a pretty popular autocomplete Search plug-in. My big challenge this week has been diving into the build tools. I read thru the webpack docs over the last couple days, then felt solid enough to try building out my Search functionality, which will return results and a map eventually. It should be noted, I'm using a scaffolding tool developed by a guy who publishes a lot of good React tutorials (from which I basically learned ReactJS -- it's called turbo360). Right now, I am using webpack 4. I just did a fresh git commit: https://github.com/ScorpIan555/real-estate-app/blob/master/webpack.config.js I have, so far, read a bit of the Babel docs. I piped in .js extentions to the .jsx test for the babel-loader, thinking perhaps that would get it? What I'm a bit confused by is that it seems to be tripping over a file written in ES5 (from the geocoder npm module I am trying to use). So, I'm wondering if I should be configuring my babel-loader to not try to transpile ES5 modules or what. This is the module I am trying to utilize, it looks fairly popular and has a recent commit. I also looked at its webpack.config.js file and tried to apply that to mine... https://github.com/abec/react-autosuggest-geocoder/blob/master/webpack.config.js
I am closing this as I received assistance on a Slack channel. This plugin uses experimental code which I do not wish to use on my app. I will use another plug-in. I was looking for help with my webpack.config and am reliably told it is fine. Thanks to all who viewed this question!
How can comments be removed from HTML files during an angular(js) build process?
This should be straightforward - Is there a way to remove comments in HTML/view output during an angular build or render processes? The goal is simple - I don't want users to see them. I know this can be done with something like Grunt or Gulp, but want the comments to be visible during development (and currently have Grunt for a build tool). I've heard this can be done using the Angular CLI, which I know is for use in Angular >=2.0 projects, but am not sure if it could be using in a 1.x/JS project.
In Angular 2+: ng build --prod creates the dist/ folder in the root. It contains via webpack stripped down code without any comments, at least with the standard configuration.
Migrate gulp process to include typescript
I am updating the build process for an Angular 1.5.8 application, to allow development on Typescript. After an over-complicated experience with Grunt, the current build process is simple and only uses Gulp and Browserify to build two bundles: my-lib.js and my-app.js. This way, the library, which is bigger, but more stable than my application code, doesn't have to compile so often and the compilation of the application-domain code only takes 0.1 sec. I am happy with that -- as well as the other developers. Now we are looking forward to migrate to Angular 2.0 and want to start development in Typescript, but I'm not sure on how to integrate it on the build process and even the best approach on how to do it: should it be preferred to use tsc only to compile Typescript into Javascript and let Browserify handle the dependencies? Or should I use tsc as my main build tool and let it resolve dependencies, create mapping files and make the bundles? Both Typescript and Gulp are evolving very fast and I cannot find documentation for this use on their documentations (1, 2). I would appreciate feedback from experienced people also working on the latest versions of these technologies.
Moving comments to answer: We have doing very similar exercise at my organization, towards the end of it. We have used webpack for most of the stuff, though webpack feels little grunt'y and after gulp, I am not a big fan of grunt. We have used webpack to convert ts to js, bunding, minification. We have not used it yet for html to js string or css in js. regarding the di part, you will have to worry about only js to ts. ts to js is not an issue as it is taken care by angular's string based di. regarding ts to ts, you will need to defined needed interfaces. Those will help you in moving those js to ts in future. Better to start with core components with least dependencies. EDIT Just to answer the part regarding the advantages of having gulp: specifically in the migration scenarios is, the upgrade is not going to happen in one go, so whatever is moved to TS should be handled by tsc and remaining by gulp. Also gulp is much larger than just ts to js, we are still using it to create deployment package, inject js into html, fixing boostrap font paths, converting small images to base64, etc etc....
tsc has one purpose: to transpile (compile) typescript files. gulp, on the other hand, is a build tool, which means it can run various tasks including compiling typescript, sass, minification, concatenation etc. You can look here for an example on how to incorporate typescript and browserify using gulp: https://www.typescriptlang.org/docs/handbook/gulp.html Another approach, is not to use gulp at all, but rather use npm scripts, you can see a sample here: https://medium.freecodecamp.com/why-i-left-gulp-and-grunt-for-npm-scripts-3d6853dd22b8#.a7lwcmpaf
I believe the absolute simplest way to do this is to use Zwitterion. You can read this article for a quick introduction. Zwitterion allows you to include TypeScript directly into the browser through normal script tags. All features of TypeScript are automatically available, because the code is transpiled server-side on a file-by-file basis as it is served to the client. Under the hood, it uses SystemJS to emulate the real ES module loader behavior that will be standard in all browsers. If you need this to work in production, you can create a static build with Zwitterion. All of this eschews bundling, so you'll have to decide on what your needs are for performance. Personally, I'm betting on performance not being that big of an issue with HTTP2, and I prefer the simplest of builds to the complication that webpack and all of its friends bring.
As you are moving forward with typescript, my recommendation would be to integrate any module bundler such as webpack (my favorite) Internally it will use ts loader to transpile the code. Also along with compile, you would be able to use ts lint for static code analysis (webpack would take care of it). Webpack also helps if you want to have multiple modules created. Try out yomen https://github.com/FountainJS/generator-fountain-webapp . Once scaffolded you can refer to generated gulp files. It would give you an idea about typescript integration.
The best way to do this without overengineering your gulp setup is to use the plain typescript compiler: 1. Install typescript locally(it won't conflict with your global tsc): npm i typescript --save-dev 2. Add tsc as npm script(inside package.json). "scripts": { "tsc": "tsc" } 3. Create proper tsconfig.json for your needs and put it in the same folder as package.json https://www.typescriptlang.org/docs/handbook/tsconfig-json.html 4. Use tsc compiler directly from gulp var child_process = require("child_process"); gulp.task("build", function(cb) { var tsc = child_process.spawn("npm", ["-s", "run", "tsc"], {stdio: "inherit", cwd: __dirname}); tsc.on("close", function(code) { console.log("Tsc finished with code", code); cb(); }); }); Tip. Use https://www.npmjs.com/package/gulp-sequence and vote up :)
Gradle for AngularJS Application
I´m pretty new to gradle and currently there is question that bugs me. The situation appears as follows: Based on a bower technology stack I implemented an Angular App. The app as it is doesn't change nor has it to be built in any way since there are just static javascript and HTML pages. In my opinion the used versions of angular, bootstrap and other libraries should also stay the same due to compatibility of the single libraries so these files also shouldn't change. Is this a correct behavior or should I get at least the latest build of the used libraries version as I deploy the application? Also less is used in the application. Is there a way to compile the CSS every time I run the gradle build file or should I deliver just the compiled and finished CSS file? As a result I´m also not quite sure if it's recommended at all using gradle to deploy an "static" angular application. I hope someone out there can help me to answer the questions above. As you can guess, I´m not very experienced at deploying of such angular applications since this is my first project with this kind of problem.
This goes for all package managers, not just gradle but npm, gem, nuget, maven, whatever. Use static dependancy version numbers. Otherwise you will end up finding breaking dependencies in QA or Prod rather than production. This means you need to be aware of security fixes in your dependencies. When you need a feature or fix in a new version of your dependencies, unlock the versions, rebuild and test in dev. Re-lock the dependencies and send to QA for verification.
MEAN.js - Should all js files be merged when deployed
I have a problem with a MEAN.js app in that its really slow to load and from the inspect i can see that its loading js in 70 different files. Couple of questions Why is there so many js files seperate? Can they not be merged into one and served quicker like YSlow advises? Edit 'modules/*/client/*.js', 'modules/*/client/**/*.js' Folder Structure modules/savings/client/controllers/client.controller.js
MEAN.js has that particular aspect covered. In fact, if you run your app using just grunt command, the app will start running in development environment, and so the js files (either the ones from 3rd party libraries or even your custom js files) are not concatenated nor minified. This helps you while debugging. However this is clearly not good for an app in production in terms of performance. If you use the command grunt prod your app will start running in production mode and so your custom js files will be concatenated and mninified. 3rd party library files won't be concatenated but grunt will use the minified version of them. You can see which assets will be loaded for both development and production modes in config/assets/development.js and config/assets/production.js, respectively. Also if you want to see what are the differences between both grunt and grunt prod tasks you can check your gruntfile.js. Note 1: The commands I mentioned about grunt can also be used with gulp, since MEAN.js has both a gruntfile.js and a gulpfile.js defined. Note 2: If, by the time you use grunt prod and still have so many files being loaded, that means you are using an high number of 3rd party libraries and a possible solution for that case is to concatenate 3rd party library files into a vendor.js file however in doing that you might run into trouble, such as some libraries like AngularJS needing the files to be loaded with a specific order. You will need extra caution if you edit your gruntfile to implement such task.