We Keep Coding

Why jQuery-migrate in not replacing depreciated functions directly in the code?

Im using jQuery-migrate on a big project. I corrected all the warnings I could but now the warnings are inside libraries.
Some libraries are not updated anymore so I can't update them to make them work with jQuery-3.3.1.
Also, I can't replace the depreciated functions directly in the libraires because it is creating errors.
So I think that I'll keep jQuery-migrate in my project.
My question is : If jQuery-migrate is able to correct the depreciated functions when called, why it can not correct them directly in the code ?

JavaScript does not lend itself to static code analysis.
Say you needed to replace the foo function.
That would be fairly trivial if the code that called it was simply:
something.foo();
It becomes rather harder if it is:
function call(bar, method) {
bar[method]();
}
call(something, "foo");
… and even harder if the logic needed to get there was more complicated.
Creating something.foo so it just exists if anything try to access it at runtime is much simpler.

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).

Require JS Object and Functions in Typescript Angular2 project

I am working with Typescript 2.1.5 and trying to write some newer sections of code with it.
I have a JS library that i am not ready to update in Typescript. The problem is that i need to consume some of that Javascript code in a simple Typescript component.
I have been fetching the web for a way to get my Javascript functions to get called and work in a .TS file. Unfortunatly informations are either outdated(mostly), not clear or not explained at all. I allready tryed a whole lot of tricks but none works.
So my question is : What is the easiest way and simplest way to consume javascript code in a TS file (ES6) ? There must be a protocol to follow to get this done.
Any tutorial, link or explanations will be much appreciated and i'am sure will help others in the same situation.
For better understanding here are some code snippets :
I start by doing an import of my JS file in the component.ts
var ZP = require('./zp.js');
In my js file i have two types of functions. Respectively a basic one and another which are methods from an object:
**export** function logTest(){
console.log("Responding");
}//Simple function
(*i just found while editing, that by appending the keyword "export" to the simple function makes it avaible to call in TS file. Wich doesn't work with methods *).
DObject.stringtest = function(){
return "Responding";
} //Object Method
Back to my component.ts file i call each one. The simple function with the export keyword now gets called, but the DObject method remains undefined.
(I made dummy calls for the DObject just to show what doesn't work even if it can seem obvious to some).
testFunc(event){
console.log("event is okay");
console.log(ZP.logTest()); <--- Now Works
console.log(ZP.stringTest()); <--- Don't Work
console.log(ZP.DObject.stringTest()); <--- Don't Work
console.log(ZP.DObject.stringTest); <--- Don't Work
}
Here are the console logs :
DObject.stringTest is not a function
( For the first two calls to stringTest() )
Undefined
( For the last call to DObject.stringTest )
( I just found something about Declaration files, i ll give it a shot, hopefully if it works i ll edit a full explained step by step tutorial. In the mean time any help would be much appreciated. )

In your case your existing javascript files are not detected in typescript because typings are not available.
you can create a type definition (index.d.ts) file and keep adding your typings so that it will be available to your tsc compiler.
Below are few thing you need to understand when coming to the typescript world. Some of you might know, some may not.
every typescript file transpiled to java script into specific version you want in tsconfig.json
typescript understand typescript ( for javascript type definition is required) or type definition.
there are many typing available in 2 forms :
typings install
#types namespace package
import and export makes available your members and properties to others

Angular methods (constants, config, run, factory, service), Does it matter what order you call them?

I have an application built on generator-angular-fullstack and it does a great job of allowing all my angular components to live in their own separate files.
I was just running all my code through JSLint and it asked to remove 'use strict'; from my index.module.js file as it worked out that this was the global or starting file for my entire application.
I was reviewing the JSLint warning here use-the-function-form-of-use-strict
This got me thinking, how did JSLint know that index.module.js was the starting code block.
Which then got me thinking, does it matter what order angular startup methods are called.
Can these methods be run in any order you like, or is there an expected sequential order for these calls?
angular.module('appName')
angular.module('appName').run(function() { });
angular.module('appName').config(function() { });
angular.module('appName').service(function() { });
angular.module('appName').constant('blah', 'blah');

TL;DR - no it's not.
The way angular is doing it - is when the page renders and scripts are loaded it register all the components(services\config\constants..) but do not execute them.
When the registration completes angular is starting to execute the application, providers --> config --> run and so on..
If your interested in some more detailed explanation on the way angular works under the hood you can check out this awesome article.
*forgot to mention that you must define your module first.

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.