We Keep Coding

What happens if polyfill script fails to download?

I have a SPA (built on webpack, with babel, etc) that includes a polyfill in the index.html:
<script src="https://cdn.polyfill.io/v2/polyfill.min.js?features=Promise,Array.prototype.includes,Element.prototype.remove"></script>
One use-case for the polyfill is in order to use the Promise API on IE 10-11.
My error monitoring reporting an error on an IE 11 client of the following:
ReferenceError: 'Promise' is undefined
So I assume that particular session failed to download the polyfill for some reason.
My question is: How should I deal with this case? Is it a scenario I should expect to happen sometimes? Is the user expected to noticed the application not working properly, and reload the page?

There is an error event you can attach to allow for more control if you are really worried. You don't usually need to handle this explicitly though.
In this particular case you could migrate towards using babel to build a bundle with polyfills included in your scripts. This adds an additional build step to your process though.

Since you mentioned you're using webpack, it would just be best to include the necessary polyfills directly in the project via an import statement (something like core.js) rather than using a cdn - polyfill.io.
However, you could alternatively add an ID to the script element and listen to the onload and onerror events to determine whether the script (un)successfully loaded like so:
<script id="polyfillScript" src="https://cdn.polyfill.io/v2/polyfill.min.js?features=Promise,Array.prototype.includes,Element.prototype.remove"></script>
In your project index.js:
document.getElementById('polyfillScript').addEventListener('error', () => {
alert('Failed to load polyfill!');
});

Intesllisense methods for expect incorrect

When using intellisense in VS-Code, it gives autocomplete suggestions for an older version of expect than what I'm using,. The API has changed since it was donated to the Jest project, but for some reason, it still shows the old methods, but none of the replacement methods, like toHaveProperty.
Took a lot of effort to find out why my tests weren't working, but haven't been able to find an answer as to what could be the cause.

VS Code sources its type definitions for JavaScript from the #types namespace on NPM, which contains definition files that are automatically pulled from the DefinitelyTyped GitHub repository.
In your case, the type definitions will be coming from the #types/expect package, which specifies in the README that it exposes the files from https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/expect.
If you look at the timestamps on said files, you'll notice they haven't been updated in 5 months! That is most likely the source of your issue.
You (or someone else) will need to submit an updated type definition to make automatic type acquisition function properly for that library. Alternatively, you can override the type definitions locally or disable the feature altogether.

libphonenumber standalone (without masses of google dependencies)? Alternate lib?

I am looking at using http://code.google.com/p/libphonenumber/ for a well-established project. Today the project does not use Google's libraries for JavaScript, favoring jQuery, jQueryUI, requirejs, and so on.
libphonenumber looks awesome ... except that the javascript version (svn co http://libphonenumber.googlecode.com/svn/trunk/javascript/ libphonenumber-js) is laced with goog.require calls. If one runs the demo (libphonenumber-js/i18n/phonenumbers/demo.html if you checked out as suggested) it pulls in tons of google libraries from closure-library.googlecode.com :
GET base.js
GET deps.js
GET error.js
GET string.js
GET asserts.js
GET array.js
GET useragent.js
GET browserfeature.js
GET tagname.js
GET classes.js
GET math.js
GET coordinate.js
GET size.js
GET object.js
GET dom.js
GET json.js
GET util.js
GET descriptor.js
GET fielddescriptor.js
GET message.js
GET serializer.js
GET objectserializer.js
GET stringbuffer.js
GET lazydeserializer.js
GET pbliteserializer.js
I believe if I compile this using the closure compiler ("If you give the use_closure_library parameter a value of true, the compiler looks for goog.require() statements in the source code and supplies the Closure Library code requested by any such statements.", https://developers.google.com/closure/compiler/docs/api-ref) I can cut down the raw number of requests, but this still seems like a rather excessive amount of content for a phone number parser, even a full-featured one.
My question has two possible answers:
A way to use libphonenumber in JavaScript without having to pull in all the Google JavaScript base libraries
An alternate standalone (as in doesn't have dozens of dependencies) first-class phone number processing library with both JavaScript and Java implementations
Any and all suggestions most appreciated.

I've got a custom build (currently 220KB) that I use for my International Telephone Input plugin, with plenty of helper functions exposed. Read the source for details.

You can also use my lib.
https://github.com/Gilshallem/phoneparser
Its only got one method but you can do a lot with it
parsePhone("12025550104");
result: { countryCode:1, areaCode:202, number:5550104, countryISOCode:"US" }

Here are two implementations of Google libphonenumber in JavaScript that have zero dependencies and are implemented in a single file. I've used Nathan Hammond's version without issue but it is not on NPM. Rui Marinho's version is on NPM.
https://github.com/nathanhammond/libphonenumber
https://github.com/ruimarinho/google-libphonenumber

I just spent 2 days figuring this out. For now, anyway, you can download a minified version of libphonenumber-js from here
drop it in place, with the usual
<script type="text/javascript" language="javascript" src="/static/js/libphonenumber-js.min.js"></script>
and get busy coding!
<script>
$(".phone-format").keyup(function () {
var val_old = $(this).val();
var newString = new libphonenumber.AsYouType('US').input(val_old);
$(this).focus().val('').val(newString);
});
</script>

Drupal CiviCRM Javascript Conflict

Installed CiviCRM in a fresh Drupal install, customized the CiviCRM and added data. The actual Drupal site was built separately in a separate install. Now that it is complete, I merged the CiviCRM with the new Drupal Site (files and database). Everything appears to work except when logged into CiviCRM: http://example.com/civicrm/dashboard it says:
"Javascript must be enabled in your browser in order to use the dashboard features."
And yes Javascript is enabled. The CiviCRM Menu is all broken and such. Chrome also reports the following errors:
Uncaught TypeError: Object # has no method 'menu'
jquery.textarearesizer.js:5Uncaught TypeError: Object # has no method 'TextAreaResizer'
main.js:6Uncaught TypeError: Object # has no method 'cycle'
jquery.textarearesizer.js:5Uncaught TypeError: Object # has no method 'TextAreaResizer'
Javascript compression under performance is not enabled. Any ideas?

CiviCRM uses the jQuery object as cj instead of $ in order to avoid conflicts with the Drupal JQuery library. In theory, they are fine using different versions because they are namespaced differently (which jQuery supports officially using noConflict()).
The conflict you have probably comes from your modifications causing either Drupal or CiviCRM to load its jQuery library at a different point in the bootstrap, or making it try to load jQuery more than once. This would make the operation to convert $ into cj pick up the Drupal jQuery object after it has already been instantiated, rather than before, leaving Drupal and/or CiviCRM without the libraries it needs being attached to the $ object (are you using # instead of $?).
Search for all code that uses noConflict() everywhere on the page in question and its JavaScript includes. You should only find it in one place. Compare with the demo.civicrm.org pages to see the difference and you'll probably find an extra one in there somewhere. Best hope for fixing it is to adjust the load order of your custom modules in the Drupal system table, or else set the second noConflict() call to run conditionally on there not being a cj object already.

I've completed a bug report. Applying this patch resolved the problem for me in a seemingly clean way. This way the jQuery library does not get loaded more than once if not necessary.

Upgrading dojo 1.3.2 to 1.4.x

Up till now my system used dojo 1.3.2 successfully. I have many Javascript files with our own declared classes which are combined together using shrinksafe to a single Javascript file.
I tried to upgrade to dojo 1.4.x (I tried several minor versions). I used the build system with a layer file with all the dojo.require()'s I use (the same one I used to build the 1.3.2 version.). The build process seems to be successful.
Unfortunately, I cannot succeed in bringing the system on the air. Firebug throws exceptions such as ... is not a constructor for my declared classes, and mixin #0 is null.
Please help !

These error point to 2 things:
1) Make sure you have a full src build of dojo.
2) The signature of dojo.declare changed in 1.4:
previously you will probably have had the following declaration for a class with no inheritance:
dojo.declare("myNamespace.classA", [], {...
In 1.4 the empty array of inherited classes will break a custom build. You should upgrade your code to the new signature of dojo.declare:
dojo.declare("myNamespace.classA", null, {...