ES6 not getting enabled in JSBin, despite selecting the “ES6 / Babel” option - javascript

I changed the drop down to “ES6 / Babel” in JSBin but it is still showing error for ES6 features. Do I need to do some additional change while enabling ES6 in JSBin?

If you hover over the yellow underlines, you’ll see a tooltip saying something like
⚠️ 'const' is available in ES6 (use esnext option) or Mozilla JS extensions (use moz).
Unfortunately, for some reason, JSBin doesn’t decide to make ESNext the default, automatically suggest making it the default, or even hint at where to find any of the mentioned options.
But fortunately, there’s Google.
There is a closed bug report with some discussion, suggesting that you can add one of the lines
// jshint esnext: true
or
/* jshint esnext: true */
at the top of your JS.
Apparently, there’s also an account setting for registered users in “Account settings” → “Preferences” → “Linting” → “jshint”, where a rule like this can be added:
{
"esnext": true
}
Unfortunately, async still won’t work, as JSHint itself complains that “'async functions' is only available in ES8 (use 'esversion: 8')”.
Note that by selecting the tab “ES6 / Babel”, you tell JSBin to transpile ES6 code down to a lower version (probably ES5.1). If your code has “errors”, i.e. uses syntax that isn’t in ES6, but a higher version, then it can’t transpile. Simply select “JavaScript” instead of “ES6 / Babel” to run JS code directly. That’ll work despite the linter showing some errors.
Here’s a few things you can try:
Try to use that esversion option in the account settings, i.e.
{
"esnext": true,
"esversion": 8
}
I didn’t get the comment variant to work, and it’s unlikely that this account option is going to work either. It seems JSBin uses an older JSHint that doesn’t support esversion.
Try to use a different Linter, e.g. ESLint, if possible, in the account settings. JSHint has had various bugs before, and is slow to adopt recent ECMAScript standards.
Use something more user-friendly and modern than JSBin.

Related

Laravel consoletvs/charts and IE11

I'm using consoletvs/charts to display charts in my Laravel application.
This works fine in all modern browsers, but I get an syntax error (and no charts displayed) in Internet Explorer 11 and below.
Tracing it down it seems this line (from consoletvs/charts, e.g. in init.blade.php line 8) is causing the (initial) error:
data => data.json()
So the culprit is the arrow operator, not supported in IE11. Using a polyfill seems to impossible (see Is there a polyfill for es6 arrow function?).
Now my questions:
Did I miss a feature in consoletvs/charts?
Is there a "Laravel" way to solve this (e.g. using babel/babel)?
Anybody got consoletvs/charts running on IE11?
Looks like you already got the answer to your question from the suggestion you got on the GitHub issues page for ConsoleTVs/Charts.
I will be changing this library to use my other tool:
https://github.com/Chartisan
This have a babel compilation step on the front-end or a pre-compiled
one. Also, the only thing needed will be the fetch() function. This
can be polyfilled.
Just stay tunned. I am writting the docs of Chartisan, and this lib
will soon be ported to that.
Reference:
Syntax Error on IE11 #554
As suggested, you should wait for the docs of Chartisan

How to disable automatic semicolon for auto imports with TypeScript and JavaScript in Visual Studio Code?

When working with VS Code and Typescript or JavaScript, VS Code suggests auto imports. But when inserting the import automatically, it will add a semicolon at the end of the line. I do not want this semicolon. In addition, it is configured in my tslint as such.
Is there anyway to tell VS Code to not to insert this semicolon?
VS Code 1.38 tries to infer if semicolons should be used for auto imports and refactoring in JavaScript and TypeScript.
With VS Code 1.39 and TypeScript 3.7+, you can also explicitly set if semicolons should be used or not:
"javascript.format.semicolons": "remove",
"typescript.format.semicolons": "remove"
(Note that until VS Code 1.40 is released, you may need to install this extension in order to actually enable TypeScript 3.7 in VS Code)
There is no way of doing that at the moment, for VSCode 1.30.2, TypeScript 3.3.
You can check out the feature request here:
https://github.com/Microsoft/TypeScript/issues/19882
But this feature may come in TypeScript 3.4, as #RyanCavanaugh updated the milestone to 3.4
In the meantime, I use semi-standard style.
Also, pure standard style does not work well in VSCode as the alignment is messed up:
function foo() {
const x = {}
;['a'].map(x => console.log(x)) // <-- alignment is bad
}
In order to add to the responses:
The setting should be
"javascript.format.semicolons": "remove",
"typescript.format.semicolons": "remove"
(Not "javascrriptscript.format.semicolons")
The docs for settings say:
"javascript.format.semicolons"
can have three different options:
"ignore" -> Dont insert or remove any semicolons.
"insert" -> Insert semicolons at statement ends.
"remove" -> Remove unnecessary semicolons.
As of now there still does not seem to be an option for the mentioned problem yet, as for me when using the autocomplete functionality for log aka console.log() it did add a semicolon to the end of the line.

Strange Javascript validation in dreamweaver CC

I've installed Dreamweaver CC 2015 and found out that I have MYRIAD errors in my working JavaScript files.
Also I have MYRIAD errors in imported JavaScript libraries, including jQuery.
The most important "error" is this one in the beginning of every working function:
Missing "use strict" statement.
It worked quite well without "use strict" and I've never even seen this statement anywhere.
Another strange one is:
Extending prototype of native object: 'Array'.
Here is the code which provokes the warning:
Array.prototype.sortOn = function(key){
this.sort(function(a, b){
if(a[key] < b[key]){
return -1;
}else if(a[key] > b[key]){
return 1;
}
return 0;
});
};
So my options are:
Ditch Dreamweaver and use another IDE (the worst, because it works perfectly fine for my purposes - I'm sole HTML/CSS/JS/PHP/MySQL developer in my project.
Fix all errors like Dreamweaver wants, because it has a good point. Then please explain why? I'm OK with changing "==" to "===", adding "var" before variable declarations, not using "return" after "if" without curly braces, but that "use strict" thing bothers me.
Tweak the JavaScript validation, so only critical errors are shown - the best option for me - but I don't know HOW to do it?
What's the best option to go with?
Any help greatly appreciated.
Here's what I figured out.
The problem was that I was not aware of JSHint and JSLint solutions for validating javascript. JSHint is integrated into Dreamweaver CC and is easily configurable, provided you know what to do.
Normally JSHint has three ways to tweak it, but they don't work in the Dreamweaver environment.
What you should do is:
From the top menu select Edit -> Preferences (Dreamweaver -> Preferences on Mac)
Choose "Linting" from the side menu.
Select "JS" and click "Edit and save changes".
The file JS.jshintrc will be opened in Dreamweaver.
Edit the file like you normally would (see JSHint options) and save.
In my specific case I changed this:
"strict":false,
"undef":false,
"unused":false
...which means that I don't have to put "use strict" everywhere and may leave definitions and usage of variables in different files. YES, I don't use wrapper functions and use lots of globals. YES, I know it's bad, but refactoring this is not the highest priority in my schedule.
Of course I will change all three those options to "true" and refactor all my JS files to comply to standards when the time comes.
Turning off the "undef" check is a sledge hammer, as JSHint will then ignore all variable and function name typos. You won't find the typo until run time, which is annoying and time wasting.
Rather than disabling the "undef" messages completely, I've been using JSHint Inline Directives near the top of my .js files. For example:
/* globals myGlobalVar, myGlobalFunction */
var myLocalVar = myGlobalVar;
myGlobalFunction();
With the globals directive in the file, JSHint will not mark myGlobalVar or myGlobalFunction() as undefined errors. Using "globals" inline directives has the added benefit of documenting the dependencies between your .js files.
Read about JSHint inline directives here:
http://jshint.com/docs/#inline-configuration

Flagging comma at last element of array as an error for JavaScript/Eclipse

I have a Javascript project that must be compatible with older versions of IE, and I am using Eclipse Juno as my IDE.
Older versions of IE cannot handle a comma after the last element of an array, even though this is correct ECMAScript:
[a,b,c,]
Unfortunately, though this is correct syntax, it breaks my application only for IE, and only in production (where backwards compatibility is forced), and in a way that is very hard to debug (it does not fail anywhere near the line that is wrong).
Is there a way to set Eclipse to flag this as an error with the syntax validator? I did not see this as an option under Preferences -> JavaScript -> Validator -> Errors/Warnings
I would warmly recommend installing jshint for eclipse which would analyze your code, and provide insightful reports about your code (including the problem you reported)
If you're not sure, just give jshint a try. Paste your code, press lint, and get the results.
Example
For the code:
var arr = [1,2,3,];
You get:
Line 1: var arr = [1,2,3,];
Extra comma. (it breaks older versions of IE)

JavaScript: Possible uses for #debug directive?

Where I work, all our JavaScript is run through a compiler before it's deployed for production release. One of the things this JavaScript compiler does (beside do things like minify), is look for lines of code that appear like this, and strip them out of the release versions of our JavaScript:
//#debug
alert("this line of code will not make it into the release build")
//#/debug
I haven't look around much but I have yet to see this //#debug directive used in any of our JavaScript.
What is it's possible usefulness? I fail to see why this could ever be a good idea and think #debug directives (whether in a language like C# or JavaScript) are generally a sign of bad programming.
Was that just a waste of time adding the functionality for //#debug or what?
If you were using a big JavaScript library like YUI that has a logger in it, it could only log debug messages when in debug mode, for performance.
Since it is a proprietary solution, we can only guess the reasons. A lot of browsers provide a console object to log various types of messages such as debug, error, etc.
You could write a custom console object is always disabled in production mode. However, the log statements will still be present, but just in a disabled state.
By having the source go though a compiler such as yours, these statements can be stripped out which will reduce the byte size of the final output.
Think of it as being equivalent to something like this:
// in a header somewhere...
// debug is off by default unless turned on at compile time
#ifndef DEBUG
#define DEBUG 0
#endif
// in your code...
var response = getSomeData({foo:1, bar:2});
#if DEBUG
console.log(response);
#endif
doStuffWith(response);
This kind of thing is perfectly acceptable in compiled languages, so why not in (preprocessed) javascript?
I think it was useful (perhaps extremely useful) back a few years, and was probably the easiest way for a majority of developers to know what was going on in their JavaScript. That was because IDE's and other tools either weren't mature enough or as widespread in their use.
I work primarily in the Microsoft stack (so I am not as familiar with other environments), but with tools like VS2008/VS2010, Fiddler and IE8's (ugh! - years behind FF) dev tools and FF tools like firebug/hammerhead/yslow/etc., peppering alerts in your JavaScript isn't really necessary anymore for debugging. (There's probably a few instances where it's useful - but not nearly as much now.) Able to step through JavaScript, inspect requests/responses, and modify on the fly really makes debugging alert statements almost obsolete.
So, the //#debug was useful - probably not so much now.
I've used following self-made stuf:
// Uncomment to enable debug messages
// var debug = true;
function ShowDebugMessage(message) {
if (debug) {
alert(message);
}
}
So when you've declared variable debug which is set to true - all ShowDebugMessage() calls would call alert() as well. So just use it in a code and forget about in place conditions like ifdef or manual commenting of the debug output lines.
For custom projects without any specific overridden console.
I would recommend using: https://github.com/sunnykgupta/jsLogger , it is authored by me.
Features:
It safely overrides the console.log. Takes care if the console is not available (oh yes, you need to factor that too.)
Stores all logs (even if they are suppressed) for later retrieval.
Handles major console functions like log, warn, error, info.
Is open for modifications and will be updated whenever new suggestions come up.

Categories