The homepage for blanket.js says I only need to data a data-cover attribute to my script tags.
But how is blanket.js supposed to modify the files before they are run?
The documentation on Github says its first step is
Loading your source files using a modified RequireJS/Require script.
Do I have to use RequireJS to get blanket.js to work?
(I cannot find anywhere where this is documented.)
Currently, I do not use requireJS, and currently, blanket.js is not working. Could this be the cause of the problem?
A while ago, Blanket used Require.js internally - I don't know if this is still true. Though, require.js was bundled with the blanket.js file. So no, you don't need to include require.js.
What you may need to include is an adapter for your Unit test Framework. https://github.com/alex-seville/blanket/tree/master/src/adapters
Related
I have a website built on the MEAN.io stack and am trying to generate PDF files on the client side with pdfmake. One can install pdfmake with bower (it looks like they used browserify to generate the client-side version).
I am struggling to get it to work. Either the injection of pdfmake does not work (I assume it cannot be found) or the pdfmake object is undefined (if I don't add pdfmake as a dependancy). I assume pdfmake needs to be packaged in some way to make it accessible, but I don't know how.
In config/assets.json I added:
"bower_components/pdfmake/build/pdfmake.js"
In the HTML corresponding to the JS file in which I want to use pdfmake I added:
<script src="bower_components/pdfmake/build/pdfmake.js"></script>
<script src="bower_components/pdfmake/build/vfs_fonts.js"></script>
I have set up a basic version on Github. I would really appreciate it if someone could explain to me how to make it possible to make pdfmake available for use in packages/system/public/controllers/index.js, for example.
I was recently have a similar problem. It seems to come from the fact that pdfmake isn't yet "browserfiable." After much troubleshooting, I was able to get it working through simply including the two client-side scripts pdfmake.min.js and vfs_fonts.js via script tags in my build directory. That's it.
Try moving the two script tags out of the bower_components directory and into your build directory. Make sure they're before your bundle.js, or generally whatever scripts need pdfmake.
I don't fully understand how bundled scripts are able to see the global objects created by these two files, but I think it's because they're setting pdfMake to the window object:
(The vfs_fonts.js file starts like this:)
window.pdfMake = window.pdfMake || {}; window.pdfMake.vfs
Since Browserify sets the global object to window, this approach seems to work. (Though I don't fully understand why... see this Github issue on their repo for more explanation and the deglobalify npm package.)
Here's another relevant post I was able to find.
How can I include a set of JS files in my Karma Config that are dynamically loaded in my code?
I'm not sure how I can load those files dynamically. We are trying to avoid having to download them and maintain them separately.
Google hasn't helped much so some help would be great.
Create a js file that loads them and add this to the list of files in the karma conf somewhere near the top.
I think there are two ways to do this kind of thing:
Include the files in the files array, specifying a pattern and setting include to false.
Have a look to the RequireJS page on the Karma website for an
idea on how this works.
Use proxies. Have a look on the Karma configuration page.
Is there a way for me to compile Handlebars templates that are loaded as individual script tags with a src attribute? For example, if I have
<script id="index-template" type="text/x-handlebars-template" src="templates/index.hbs">
I know I can precompile them, but I cannot introduce this step as it requires npm + my company doesn't use it.
I tried to find some way to use jQuery to get the source of the loaded file, but couldn't figure it out. Also, I know I can use AJAX, but I'm looking for another solution.
Precompilation requires Node.js. If you can't have it installed on every developer's machine, you may create a service for others to use (I can't find any existing one).
If you want to compile templates run-time, you can get them using AJAX. If the file have already been downloaded, it will be taken from cache. It is still an async operation, so you may use the same syntax for processing the result.
Funnily enough, I just wrote a Handlebars precompile bundler today to use with the asp.net optimization library. It takes advantage of Jurassic, as is explained here.
I have yet to put it in a github repo, but it will be once I make it slightly more generic. I will edit the post and point to the repo later tonight if anyone is interested.
It does take dependencies on Jurassic as well as System.Web.Optimization 1.1.
I think the question says most of it. I have an autogenerated ManualSpecRunner.html file as created by maven / jasmine plug-in and I've got it to put itself into the deployable .war by using:
<jasmineTargetDir>${basedir}/pathForMyWebapp</jasmineTargetDir>
However, all the links to js files within the ManualSpecRunner.html are hard coded file:/// references - this is a bit mental, I want them to just be the relative paths to the files that are also in the webapp i.e.
Currently it gives me this path:
file:///home/username/code/HEAD/pathForMyWebapp/js/yui.js
whereas I need it to have the far more simple
/pathForMyWebapp/js/yui.js
I have tried changing two other variables in the maven script, but neither seems to have the desired effect, neither of these configuration options do what I need, the second having seemingly no effect:
<jsSrcDir>/pathForMyWebapp</jsSrcDir>
nor
<jsTestSrcDir>/pathForMyWebapp</jsTestSrcDir>
I've looked through the documentation but think I must be missing something (also, more notes on various config params listed in https://github.com/searls/jasmine-maven-plugin/blob/master/src/main/java/com/github/searls/jasmine/AbstractJasmineMojo.java are meant to do would be helpful so I can work out if I'm doing it wrong or if it's not possible!)
Any suggestions?
[p.s. I've changed some of the path names as they've got sensitive info in them, so please ignore their oddness!]
I think I understand the source of your confusion. It looks like you're trying to direct the target of the jasmine-maven-plugin to a directory inside your project's packaged *.war file so that you can run your specs against the code after it's deployed to a server, is that correct?
Unfortunately, the plugin wasn't designed with that use in mind. The jasmineTargetDir directory is usually left at its default value of target/jasmine and wasn't intended to be bundled with your application (it's analogous to the target/surefire-reports generated by maven-surefire-plugin for Java unit tests). So the reason that the script tags in ManualSpecRunner.html point to invalid locations is because that file is generated in order to be run from the local filesystem in a browser from the workstation that's building the project (to facilitate TDD).
All of that to say, if I'm reading your intention right, I think it'd be a cool feature to build a third spec runner that could be deployed with the app and executed remotely. (Especially if the project's Jasmine specs are functional/integration as opposed to isolated unit tests.) Unfortunately that's not something the project does yet.
I'm afraid that for now, if you needed to bundle the jasmine tests and execute them on the deployed server, you would need to copy ManualSpecRunner.html and jasmine into your src/main/webapp, fix the script tag references, and then manually maintain it as files are added and removed.
Make sense?
I took a snapshot of the jquery.js file and jquery-ui files that I use and dumped them into a giant .js file with all of the other .js files that I use for my site.
When I do just this with no minfication/packing, the files stop working and I get "recursion too deep" errors on the file when I try to load it on my site instead of the usual .js files. All of the errors came from jquery and jquery-ui. Using a simple numbering scheme I made sure that the jquery.js/jquery-ui files were the first listed in the file and in the correct order (the same as includes as individual files.)
Two questions:
1) Doesn't the include tags for JavaScript have the same effect as dumping all of the files into one giant file? Is there extra isolation/insulation that JavaScript files get from being in their own script tags or in different files?
2) My goal is to make my site faster by having one huge .js file with all JavaScript I ever use in my site (which is heavy in JQuery) and minify that file. Why is this misguided? What is a better way to do it?
NOTE: Google's CDN version of the JQuery files don't work for me, all of the JQuery plugins/themes I use don't work with Google's versions (anyway who says that they can successfully use Google's CDN is lying.)
UPDATE: Thanks for the good advice in the answers, all of it helped me learn more about deploying JavaScript files on a production server. I am actually always using the latest SVN branch of the JQuery UI plugins and there were errors in the UI plugins that prevented them from being merged together with my files. I got the latest Theme Rolled plugins that are already minified in one file and that worked around the problem.
Probably your JavaScript files have some syntax errors. Browser can correct them when loading files one by one, but fail when "bad" files combined. You can try to compile your file using Rhino compiler (http://www.mozilla.org/rhino/)
java -cp build/js.jar org.mozilla.javascript.tools.jsc.Main giant.js
Also you can use JSLint validator (http://www.jslint.com/), thought likelly it will not be able to handle jQuery. But you still can combine all your files and validate them.
I'd recommend using a script manager such as this one to only register the files and plugins you need, and load them on the fly.
This keeps your requests to a minimum, and you don't have to load some huge 300k JS file one very page.
Another problem could be the load order changed. Most JavaScript files should be load order independent, but if you load jquery at the end after you have your:
$(document).ready(function() {});
you'll run into problems.