Update: I was able to solve the issue. One of the third part scripts I was including was missing a semicolon, thereby breaking the closure. When the minified version was being used, the generator didn't know where the block ended and new blocks began. The grunt build process works fine as is now, without modification.
I've got an angular app that I built with the generator-angular yeoman generator and it works wonderfully in the local "grunt serve" state. When I run "grunt build," however, the built version doesn't work properly. I'm using the standard Gruntfile that comes with the generator.
The only different between the grunt serve and the grunt build tasks are the minification, concatenation and uglification of files. You'd think it would simply concat and minify the files in the same order it loads them in the development build, but it looks like things are being loaded in a different order—throwing a app.init() is not a function error—which tells me the app module isn't loaded before that section.
Is there something that needs to be done to the default build task to fix this issue?
I'm not sure what the problem is, but I think that can be the minification process, there are several ways of writing a controller and some of them have problems at the time of the minification.
If the problem is the minification you could check these pages.
AnularJs - A note on minification
Best Practice of Minification StackOverflow
Example about minifying AngularJs Controllers
Related
I could not find any explanation regarding the work of "npm run build",
It is simple and easy to use and i get the "build" folder that works great,
But, in create-react-app, what happens exactly behind the scene?
Is it a complete different use of a build tool?
If not, is it utilizing other build tools?
Developers often break JavaScript and CSS out into separate files. Separate files let you focus on writing more modular chunks of code that do one single thing. Files that do one thing decrease your cognitive load as maintaining them is a quite cumbersome task.
What happens exactly behind the scene?
When it’s time to move your app to production, having multiple JavaScript or CSS files isn’t ideal. When a user visits your site, each of your files will require an additional HTTP request, making your site slower to load.
So to remedy this, you can create a “build” of our app, which merges all your CSS files into one file, and does the same with your JavaScript. This way, you minimize the number and size of files the user gets. To create this “build”, you use a “build tool”. Hence the use of npm run build.
As you have rightly mentioned that running the command (npm run build) creates you a build directory. Now suppose you have a bunch of CSS and JS files in your app:
css/
mpp.css
design.css
visuals.css
...
js/
service.js
validator.js
container.js
...
After you run npm run build your build directory will be:
build/
static/
css/
main.css
js/
main.js
Now your app has very few files. The app is still the same but got compacted to a small package called build.
Final Verdict:
You might wonder why a build is even worth it, if all it does is save your users a few milliseconds of load time. Well, if you’re making a site just for yourself or a few other people, you don’t have to bother with this. Generating a build of your project is only necessary for high traffic sites (or sites that you hope will be high traffic soon).
If you’re just learning development, or only making sites with very low traffic, generating a build might not be worth your time.
It's briefly explained here: https://github.com/facebookincubator/create-react-app#npm-run-build-or-yarn-build.
It correctly bundles React in production mode and optimizes the build for the best performance.
The build is minified and the filenames include the hashes.
Behind the scenes, it uses babel to transpile your code and webpack as the build tool to bundle up your application.
I am trying to get started with the yeoman generator Angular-Fullstack. I am using TypeScript, but when I compile and run all the js files get put into one large app.js. This would be fine for production, but for debugging its a hassle. Does anyone know how to change this so just the compiles JS shows and gets executed?
EDIT
I am using the default gulp.babel.js file for all of the configurations. There is no grunt file, so alas those links are to a different issue.
I assume that file is for Grunt's build task, however, there is no configuration for coffee script compiling in the Gruntfile. This seemingly irrelevant file makes me wonder if the maintainers of the Yeoman Angular project put it there for a good reason, which makes me a bit paranoid to straight out remove it.
Yes, you can remove it with no worries, especially if you have nothing in it. If you're really worried, move it to a different folder and run a build, then if it fails you can move it back.
From experimenting with the r.js optimizer, it seems that there is no way for your final index.html file to just reference a single script and never make any async calls to other scripts during the lifetime of a user's session (unless they reload the page of course). From my experience, it looks like it creates a bunch of combined groups of optimized files which can be referenced when needed? This seems counterintuitive to most combine scripts where you end up with just one combined/optimized js file that is in the correct order. Can anyone help explain my issue?
Yeah, that's how r.js works, it optimize your dependencies into one or multiple file (you'd use include option to get all your file togheter).
Although, this build will keep require.js script file out of the build. But, after the build, you can combine require.js (or minimal AMD implementation like almond.js) at the top of your builded file and it will all work mostly fine (some problem may occur depending on how you bootstrap your app, but most of the time those issues are pretty easy to resolve).
To combine the files easily, you can use tools like grunt.js (I really recommend it to you as it can do much more and is really a must have in frontend developpement workflow). If you work with backbone app, you can checkout (Backbone Boilerplate)[https://github.com/tbranyen/backbone-boilerplate] and their grunt implementation.
I have a rails app that is combining javascript assets using Jammit, and I'd like to use Jasmine for BDD-style testing of my javascript. I'm wondering if anyone has any advice on accessing the Jammit-generated 'pacakges' from within Jasmine?
The issue is that Jasmine is configured by defining a list of JS files on disk to test, and it then includes those files within its own test runner page which is loaded and run in a browser.
I could reference each of the individual JS files inside of the jasmine.yml config file before they're packaged with Jammit... however, Jammit is already dealing with dependencies between files for me, and, more importantly, I also need access to the compiled javascript templates that Jammit produces.
I could also manually run Jammit to generate the compiled assets first and then run Jasmine, but I'd wind up having to re-generate the assets by hand before each test run in order to test changes, which would seriously cramp a fast test-driven type workflow.
I'm wondering if I could somehow:
Mount the Jammit controller from within Jasmine's rack server so it could serve out the packages from Jasmine? This would basically work the same way as Jammit already does from within Rails' development env.
Hook into Jasmine somehow to package the assets on every page load before the tests are executed? This would be slower, but would save me a step and ensure things were up to date.
Any suggestions? I'm just getting started with this, so I could be going about it all wrong. Any advice would be greatly appreciated. :-)
Thanks!
-John
Here's the magic combo you're looking for:
Use the guard gem along with the guard-jammit gem to watch for changes to your project's assets
Install the LiveReload plugin in the browser of your choice and install the guard-livereload gem so you can have your browser auto reload whenever your specs or assets change.
Fire up guard, then rake jasmine, then load your jasmine specs in your browser, then press the live-reload button to connect to the live-reload server that guard started
Change your files. Watch the magic happen as guard runs jammit and instructs your browser to refresh the jasmine specs.
Here's an example Guardfile to get you started:
guard 'jammit' do
watch(%r{public/javascripts/(.*)\.js})
watch(%r{app/views/jst/(.*)\.jst})
watch(%r{public/stylesheets/(.*)\.css})
end
guard 'livereload', :apply_js_live => false do
watch(%r{app/.+\.(erb|haml)})
watch(%r{app/helpers/.+\.rb})
watch(%r{public/.+\.(css|js|html)})
watch(%r{config/locales/.+\.yml})
watch(%r{spec/javascripts/.+\.js})
end
I've come up with an OK solution: force Jammit to reload and package when jasmine starts. To do this, you need to edit the jasmine_config.rb file:
require 'jammit'
module Jasmine
class Config
Jammit.reload!
Jammit.package!
end
end
I wrote a bit more detailed post about it here: http://www.rebeccamiller-webster.com/2011/05/jammit-jasmine-bdd/