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.

JavaScript/Swift + JavaScriptCore - Possible to ignore undefined variables?

I've got a web scraper-ish set of functions that I'm writing in Swift, and I'm using the JavaScriptCore library to... well, execute some JavaScript. I've scraped a file from the web, but it only has a couple of functions that I'm interested in. However, parts of the file contain things like window or window.currentScript, or new window.WeakMap... these things are unfortunately not defined in JavaScriptCore.
This is one of the errors that I'm getting, for example:
TypeError: undefined is not an object (evaluating 'window.document.currentScript.src.indexOf')
Something I'm attempting to do in the meantime is monkeypatch all of the erroring things, like this:
window={};window.document.currentScript.src={};window.document.currentScript.src.indexOf={}
And prepending this to the JS. However, there must be a better way... right?

What I ended up doing was disregarding these references to window altogether—the functions I needed from the JS file didn't ever reference window or its properties. I did some regex magic (magix?) to extract the definitions of the functions I wanted, and made a new string for just those functions. Then, I gave that string to JSContext.evaluateScript. I hope this helps someone!

globalVars In less file

I'm wondering if there is any chance to get all the defined variables inside escaped less javascript code.
e.g.
#allvars: `(function(){ return globalVars;})()`;
its urgents for a project I'm working on.
Just for the record, I just need the already defined ones.
Not all variables in all files.
Thanks for the help

Im doing it that way now
.theme(#theme) {&{.compile(#theme);}}
usage:
.theme(main) // will compile all mixins in .compile() for given theme
inside the compiler mixin I do this
.compile(#theme) {&{
#base-color: 'theme-#{theme}-base-color';
.another-module(##base-color);
}}
In that way I have seperated the compiling proccess completely form the assigning of themes. works like charm here.
Sure it's a lot of typing to reassign all the colors, but god bless multiedit.
And you just do it once for each module so who cares after all.
Hope this helps someone else

Typescript and sql.js - how to tell Typescript it's there

I might be approaching this completely incorrectly, so any advice is appreciated. I'm currently trying to dig in deep to Typescript, and have decided to simultaneously use Sql.js (the JS version of SQLite) at the same time...
My first instinct to use Sql.js was to search for a .d.ts set of bindings around Sql.js so that I could easily start using it with TS. I've come up with no bindings so far (I don't think one exists yet), but figured I could just start "define"-ing in the stuff that I need from the library...
Starting with one of the simple examples from the "sql.js" docs, you have something like this:
var sql = window.SQL;
var db = new sql.Database();
Moving to the typescript side, I wanted to let TS know that after the sql.js library is included, the window object now has a property called SQL, which is essentially the hook to the rest of the library. I figured I needed to do this because, of course, when I type "window." (window-dot) in Visual Studio in my TS file, the Intellisense presented doesn't know about the SQL property now hanging off of "window". So... I dug around Stack, and concluded that I could solve this with a "declare" which I basically see as a way to tell TS just enough about the libraries that I don't have binding files for (.d.ts files).
However, in doing this, I can't seem to construct the syntax for such a declaration. I've tried:
declare var window.SQL : any;
declare var window.SQL;
declare var SQL = window.SQL;
declare window.SQL;
None of these work, of course.
So, the question is, how can I let TS know about new properties introduced by JS libraries on standard objects like "window", and the follow up question is, of course, is this even the right way to be approaching this?
Thanks for any insight.

Now that we have type definitions for SQL.js, and as of Typescript 2.0, the ability to install them easily, you can just do this:
npm install #types/sql.js
Then, that typings file will automatically be picked up by the compiler, and it will know that there is a SQL object. Here is the full definition:
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/sql.js/sql.js.d.ts

window is declared to be of type interface Window (in lib.d.ts). So you need to add to that if you want to use window.SQL :
interface Window{
SQL:any;
}
var sql = window.SQL;
var db = new sql.Database();
Recommend:
Personally I would recommend not using it off of window and just do
declare var SQL:any;
var db = new SQL.Database();
By default the variable access in the browser is on window.

OK, I think I've figured it out, although I'm still not sure if this is the preferred method.
In inspecting lib.d.ts, which is pretty much the heart of the sun as far as declarations go, I found the declaration of the interface for Window more than once. That led me to the conclusion that TS interface declarations (and likely other declarations) can essentially be "partials". It appears that the definition of any interface can be extended by simply adding extra items in a brand new declaration...
So, currently, my angry red squiggly line under "window.SQL" has gone away by simply adding the following:
interface Window {
SQL: any;
}
This seems to work because in lib.d.ts, the "window" variable is defined as a "Window" like this:
declare var window: Window;
... on line 9867 of the file in case others are looking for it. So, the net effect seems to be, I extended the definition of "Window" based on knowing that sql.js would make a new property called "SQL" on it.
HTH, in case anyone else is spelunking the same concepts.

Changing the main environment in Node

Some of you may or may not (probably not) know about my framework. It's name is Ally, and I absolutely love using it.
Lately I've been doing a little bit of stuff in Node.js. Today I decided I was going to use it as my HTTP server, so that I could do server-side JS (in a PHP kind of way).
To do this, I started a project I'm calling Trailer . While working on it, I found myself needing one of Ally's functions, Object:deploy. What it does is pretty much this:
var a = { a: 'a' };
a.deploy({ b: 'b' });
a.a; // 'a'
a.b; // 'b'
So I loaded it in..
var Ally = require('./Ally.js');
..but when I tried using it, it said it was undefined.
After a bit of digging I discovered that Object:deploy is defined in the Ally.js file, but the changes it makes to the global constructors don't stay.
How do I make the changes to global variables in the Ally.js file apply to the global variables in the file that required it?
Note: Ally is linked to above if looking through the source could help, and Trailer is linked to in case anyone wants to use it when I get a usable version out.

Is this discussion relevant? The key points here seem to be:
require won't extend global objects if you're working in the shell
It also won't work when NODE_MODULE_CONTEXTS = 1, though this doesn't seem to be the default for a script.
So if you're trying to run this in an interactive shell, that might be the issue. See also this SO question.