We Keep Coding

Adobe AEM form with custom javascript events throwing guideLib, guide.js, guideBridge, or guideRuntime undefined or ... is not a function

This is going to be a problem that very few if any people have, but it was time consuming and difficult to solve and i figured it out, so here is the solution, one other person in the world who has this problem.
Are you getting all kinds of weird "this.getOnOffValueFromModelValue is not a function" kinds of errors from guideRuntime.js, guide.js , or guidelib -- or other adobe frontend libraries that you do not control?
These may not apply to you directly but if they do definitely keep reading:
Are you using webpack and including custom code on the page elsewhere (perhaps via a data-sly-use or something)?
Does your project use lodash? or perhaps another library that uses a "_" global variable?
Or perhaps jQuery? or other frontend library?
Then you may be asking questions like:
Why is my form not working properly?
Why is some stuff on the form just not working?
Some rules are just not working... why not and how do i fix them?
Oh I'll feed you, baby birds.
( can someone with a higher reputation add the tags adobe-form, aem-form to this, please)

TLDR:
If you're using Webpack, add this to your module rules:
module: {
rules: [
{ parser: { amd: false } }
// ... your other rules
]
}
or if you're not using webpack, make sure your own variables are not leaking into the global scope, because adobe's are and yours may overwrite theirs or vice-versa.
The explanation that may be applicable even if you're not using webpack that may get you in the right direction:
Adobe's client libraries (like guide.js and guideRuntime and the like) aren't particularly good at dependency injecting their stuff. Their code leaks global variables a lot. For example (see picture below) they use underscore's _.each a lot. if you're using lodash, the function signatures are different-- underscores' allows you to define a "this" context as the third parameter, whereas lodash's doesn't.
So, in our case, our lodash was overwriting their underscore causing a bunch of weird issues... EVEN THOUGH we were NOT declaring lodash globally anywhere. WEBPACK WAS defining lodash globally
So moral of the story, open up console, check to see if any of your libraries are defined globally, and if they are, figure out how to make them not global until Adobe decides to fix their stuff (don't hold your breath).

Strage behaviour using Knockout.js 3.2.0, shift is undefined

This one's been a real hair-puller.
I moved some divs into templates without altering any ko's datacontext, and all of a sudden I had the dreaded "undefined is not a function" in template.
Turns out it wasn't something related to a missing observable, but something internal to ko:
Looks like continuousNodeArray is not a plain-old array but it's a jQuery object array (I assume in this particular instance only, as I believe it should be a plain-old array).
So I'm curious to know if this is a Knockout.js bug or something in my templates triggering this behaviour. I solved this by adding the following:
jQuery.fn.shift = [].shift;
But I'm sure there must be something else going on. Any clue?

This is known and not recently (Oct 8) fixed bug when you are using jquery.tmpl as a templating engine.
See on github: Fix error in fixUpContinuousNodeArray when using jquery.tmpl
So if you check the latest source you will see now that splice is used instead of shift:
However it is not included in the latest version (3.2.0) so you properly should stick to your workaround until a new version comes out.

Recent change to underscore.js has broken Backbone.ModelBinder. How to proceed?

I recently started using Backbone.js (which uses underscore.js) and wanted to supplement using Backbone.ModelBinder https://github.com/theironcook/Backbone.ModelBinder.
It appears that a recent change to the bindAll() method in underscore.js has broken the examples provided with Backbone.ModelBinder. Apparently, it now throws an exception if no functions are provided in the call.
I have "fixed" the problem by changing one line of code in the constructor:
_.bindAll(this); is now replaced with
_.bindAll.apply(_, [this].concat(_.functions(this)));
(this was thanks to a thread at https://github.com/documentcloud/underscore/commit/bf657be243a075b5e72acc8a83e6f12a564d8f55)
The examples now seem to work but I am wondering if there are other landmines I will encounter? Would I be better off to revert to a prior version of underscore.js until the good folks at theironcook put out a compatible version of Backbone.ModelBinder?

initialization of dojo widget

I tried to create custom widget for my site. when I loaded page it says:
mixin #0 is not a callable constructor.
clsInfo.cls.prototype is undefined
I can't find any information about clsInfo, so I don't know what is it. maybe the problem that I use dojo from google:
and my own script is located on localhost. so when my dojo on page initializes something goes wrong with my script. I can't find any good info on dojo, maybe I search in wrong places?
please help me to resolve my problem

I ran into this when I was trying to override a dijit.Dialog so I could bind events to controls within it. We've yet to see if the binding part will work, but if you look at the source, this happens when one of the bases passed in as the second argument fails to resolve to an "[Object function]". In my case, I was passing a String in.
dojo.declare takes 3 arguments:
The name of the custom object "class" you're building
An array of base classes, parents to provide functionality (not the string names of those classes)
A hash of functions and declarations
So if I want to override dijit.Dialog, I have to do:
dojo.declare("myDialogType", [dijit.Dialog], {
function1() {/*Code*/},
function2() {/*Code*/}
}
I had ["dijit.Dialog"] as my second argument and that was the problem.
I strongly recommend using Web Inspector or Firebug with uncompressed local copies of the Dojo library rather than the CDN to figure out what's going on and debug these types of problems. Dojo's documentation is extensive but not complete in some areas and some behaviors have to be figured out by looking at what the code expects. That's not intended as a slight to the authors; once you get it going it's a pretty awesome product, and any documentation for volunteer work is appreciated.

Are you sure Dojo is loading? Did you put your code in a dojo.addOnLoad()? When using a CDN you sometimes run into issues with execution times. dojo.addOnLoad() will not only trigger when the DOM is loaded, it gets called when dojo resources have downloaded, such as dijit._Widget.

I've run into this problem when I screw up the order of my requires which makes _WidgetBase not what _WidgetBase really is. Seems like a simple spot to screw up.

prototype and jQuery peaceful co-existence?

I know very little about JavaScript but despite this I'm trying to cobble something together on my wordpress blog. It's not working, and I don't know how to resolve it, and hey, that's what StackOverflow is for, right?
Firstly, the error message is:
Error: element.dispatchEvent is not a function
Source File: http://.../wp-includes/js/prototype.js?ver=1.6
Line: 3936
It happens on page load. My page load handler is registered thusly:
Event.observe(window, 'load', show_dates_as_local_time);
The error goes away if I disable some other plugins, and this (plus googling) led me to conclude that it was a conflict between prototype and jQuery (which is used by some of the other plugins).
Secondly I'm following the wordpress recommended practice of using wp_enqeue_script to add a dependency from my JavaScript to the Prototype library, as follows:
add_action( 'wp_print_scripts', 'depo_theme_add_javascript' );
function depo_theme_add_javascript() {
wp_enqueue_script('friendly_dates', 'javascript/friendly_dates.js', array('prototype'));
}
Now I'm also aware that there are some potential conflicts between jQuery and Prototype which are resolved using the jQuery noConflicts method. I've tried calling that from various places but no good. I don't think this is the problem because a) the noConflict function relates solely to the $ variable, which doesn't seem to be the problem here, and b) I would expect wordpress to sort it out for me because it can...
Lastly, using the Venkman debugger I've determined that the element referenced in the error message is indeed an HTMLDocument but also does lack a dispatchEvent. Not sure how this could happen, given it's a standard DOM method?

There is a nasty trick many libraries do that I've taken a distinct liking to, and it looks like prototype is one of these.
Mootools does this, If I am right, and it involves overloading many of the prototypes on the basic classes, monkey patching them.
And likewise, I similarly encountered strange behaviour when mootools and jQuery were present, usually jQuery dying because it was calling some object method which had been somehow overloaded/monkey patched by Mootools.
Also, mysteriously, taking mootools out of the script usage list, resulted in everything running much faster, which I concluded was due to less object pollution.
Now I could be wrong, but I concluded from my experience such libraries just simply don't like to co-exist with each other, and seeing how mootools code seemed to me to degrade speed at which normal things were done, I sucked up and ported all mootools based code to jQuery ( A time consuming deal I assure you ), and the result, was code that was fast and didn't have weird errors that were unexplainable.
I recommend you consider migration as at least One of your options.
One More thing, when writing:
I tend to use this syntax with all my jQuery driven code, for a bit of safe encapsulation in the event somebody breaks '$' somehow.
Runtime Code
This waits for document.ready before executing:
jQuery(function($){
code_with_$_here;
});
jQuery Plugins
(function($){
code_with_$_here;
})(jQuery);
Using these will make it easier for people using any jQuery you happen to write to be able to use it without much of a conflict issue.
This will basically leave them to make sure their code isn't doing anything really magical.

Its worth reading this article on the JQuery site about Using JQuery With Other Libraries. It deals with more than just the noConflict option.

I think you should search well because all jQuery plugins has a prototype version and all prototype plugins has a jQuery version.
If you really don't find what you look and you can't use only one library, take a look here at
jQuery.noConflict();
But again, i think it make no sense to load over 15-20kb for each library :)

Thanks for the suggestions all. In the end I think Kent's explanation was the closest, which basically amounted to "Prototype is broken". (Sorry if I'm summarizing you incorrectly :)
As for the jQuery.noConflict option - I already mentioned this in the question. It makes a difference when you run this method, and I have very little control over that. As I said, I have tried running it in a couple of different places (specifically the page header and also from my script file), to no effect. So, much as we'd all like it to be, "just use noConflict" is not an answer to this question, at least not without additional information.
Besides, jQuery.noConflict seems to be about the $ variable, and the code around the error point does not deal with that variable at all. Of course they could be related indirectly, I haven't tracked it down.
So basically I ended up rewriting the script using jQuery instead of Prototype, which actually had its own problems. Anyway I've published the whole war story on my blog, should you be interested.