Develop Reference

How can I enable references in WebAssembly with SpiderMonkey?

I try to use the experimental AnyRef in WebAssembly with the JavaScript engine SpiderMonkey. I receive the follow error:
CompileError: wasm validation error: at offset 40: reference types not enabled
I try to enable it with the command line parameter --wasm-gc but without luck. Any idea how I can do it?
I call it like:
js --wasm-gc test.js

Using anyref is a little tricky at the moment because the feature is in an inbetween state; it'll "just work" once we land some of the missing pieces.
Currently you need not only the command line switch but also an explicit opt-in in the module itself.
In the text mode (if you're using the built-in wasmTextToBinary function in the SpiderMonkey shell) you must have a custom section at the beginning of the module that looks like this:
(gc_feature_opt_in 1)
If you're generating binary code, the encoding is documented here: https://github.com/lars-t-hansen/moz-gc-experiments/blob/master/version1.md

Turns warnings into errors in Ember.JS

Is it possible to throw warnings as errors in Ember application. I found
Ember.ENV.RAISE_ON_DEPRECATION = true
but as I understand it works only for depreciation warning.
I want to throw warnings like
"WARNING: Binding style attributes may introduce cross-site scripting vulnerabilities; please ensure that values being bound are properly escaped. For more information, including how to disable this warning, see http://emberjs.com/deprecations/v1.x/#toc_warning-when-binding-style-attributes30."

You can use Ember.Logger.warn or Ember.warn. The differences between the two is that the second in a production build, is defined as an empty function.
Ember.Logger.warnseems undocumented but you can give a look at the source code https://github.com/emberjs/ember.js/blob/master/packages/ember-console/lib/index.js#L81.
Docs for Ember.warn: http://emberjs.com/api/#method_warn

When creating a linter, what is the expected output format?

Linting is an invaluable technique when crafting code. Yet I find myself wanting to understand the process of linting more. To do this, I am building a basic static code analysis tool with node.
What the linter should do is perform a regex check and if the regex matches, throw an error (or warning depending on the user's config).
I understand that linters traditionally parse code and some even execute checks on an AST, but I want to avoid this entirely. I also understand that my method is bypassing nearly every important part of linting by avoiding the parsed syntax altogether.
The goal is to be able to write a few dead-simple checks and have this as an accessory linter for rapid prototyping. (example: put ^$\n^$ into my linter config and an error would be thrown for two continuous blank lines)
The part of the process that seems undocumented is what type of output is expected to the command line. Here is example output from xo:
/Users/dawsonbotsford/code/regexLinter/cli.js
42:9 error Expected indentation of 6 space characters but found 8 indent
43:9 error Expected indentation of 6 space characters but found 8 indent
43:32 error Missing semicolon semi
And eslint example output:
/Users/dawsonbotsford/code/regexLinter/cli.js
3:1 error Parsing error: The keyword 'const' is reserved
How would I mimic this output with the correct types of shell errors/warnings such that it would be pluggable into sublime-contrib plugins, CI servers, etc.?

If you want it to be pluggable the simplest you can do is write a plugin for ESLint if you need to capture formatting issues. If you want to transform code use 🐊Putout, the tool I’m working on, it also has a plugin for ESLint so the messages you are going to show, will be accessible in terminal, IDE, CI etc.

Is TypeScript really a superset of JavaScript?

I just started using TypeScript and sometimes get compiler errors "use of undeclared variable". For example the following works in plain JavaScript :
var foo = {};
foo.bar = 42;
If I try to do the same in TypeScript it won't work and give me the mentioned error above. I have to write it like that:
var foo :any = {};
foo.bar = 42;
In plain JavaScript the type definition with any is neither required nor valid, but in TypeScript this seems to be mandatory. I understand the error and the reason for it, but I always heard in Videos and read in the documentation:
typescriptlang.org:
"TypeScript is a typed superset of JavaScript [...]"
Introduction Video #minute 3:20:
"All JavaScript code is TypeScript code, simply copy and paste"
Is that a thing that changed during the development of TypeScript or do I have to pass a specific compiler setting to make this work?

The reason for TypeScript's existence is to have a compiler and language which can enforce types better than vanilla Javascript does. Any regular Javascript is valid TypeScript, syntactically. That does not mean that the compiler must be entirely happy with it. Vanilla Javascript often contains code which is problematic in terms of type security. That doesn't make it invalid TypeScript code, but it's exactly the reason why TypeScript exists and it's exactly the compiler's job to point out those problems to you.
The languages as such are still sub/supersets of one another.

Theorem: TypeScript is neither a subset nor a superset of JavaScript.
Proof:
When we say language A is a subset of language B, we mean all valid A-programs are also valid B-programs.
Here is a valid TypeScript program that is not a valid JavaScript program:
let x: number = 3;
You identified a valid JavaScript program that is not a valid TypeScript program:
var foo = {};
foo.bar = 42;
Complicating factor 1: TypeScript is almost a superset. TypeScript is intended to be a near superset of JavaScript. Most valid JS is also valid TS. What JS is not can usually be easily tweaked to compile without errors in TS. In other words, most valid JS is also valid TS.
Complicating factor 2: non-fatal errors The TypeScript compiler generates the JavaScript code you intend sometimes even if there are errors. The your example that I referenced earlier emits this error
error TS2339: Property 'bar' does not exist on type '{}'.
but also this JS code
var foo = {};
foo.bar = 42;
The TS documentation notes
You can use TypeScript even if there are errors in your code. But in this case, TypeScript is warning that your code will likely not run as expected.
I think we can call this a failed compilation (and thus invalid TypeScript) for the following reasons:
The compiler seems to use the term warning in the conventional sense, so we should interpret error in the conventional sense too: an error indicates the compilation failed.
The documentation indicates that the resulting JavaScript is not necessarily correct as to what was intended. An incorrect output seems just as bad as (if not worse than) no output. They should both be considered failed.
The TypeScript compiler exits with a non-zero status code, which conventionally indicates that the process failed in some way.
If we call any TypeScript program that outputs JavaScript "valid", then we would have to call the following TypeScript program valid, because it a dot compiles to the empty string after issuing errors:
.
Complicating factor 3: TS accepts JS files: The TypeScript compiler can passthrough files ending in .js (see compiler documentation for --allowJs). In this sense TypeScript is a superset of JS. All .js files can be compiled with TypeScript. This is probably not what people who visit this question are meaning to ask.
I think complicating factor 1 is the thing that Anders Hejlsberg is getting at. It might also justify the misleading marketing on TypeScript's homepage. The other answers have fallen prey to complicating factor 2. However the general advice given in the other answers is correct: TypeScript is a layer on top of JavaScript designed to tell you when you do something bad. They are different tools for different purposes.

No. In other answers I believe the technical reason has been well explained, but I notice an example that could immediately serve as a contradiction to the claim in the question (different semantics):
// In TypeScript
function f<A>(a: A) { return a; };
console.log(f<Function>(f)); // <-- This line. It will print the function f since it is an identify function that in this case takes self and returns self.
Comparing to the below JavaScript example
// In JavaScript
function f(a) { return a; };
console.log(f<Function>(f)); // <-- This line. This is VALID JavaScript
At first glance you might think there should be a syntax error for the JavaScript example. HOWEVER, once you examine it closely, you'll notice that actually the line is executed as
console.log((f < Function) > f); // Evaluate to false
which is completely valid in JavaScript. This essentially means the same line of code resulted in 2 completely different interpretation in JavaScript and TypeScript, therefore a counterexample to the question.

The definition
"All JavaScript code is TypeScript code, simply copy and paste"
is true. Because any JavaScript code can passed to the TypeScript compiler.
So it's sort of a Layer on top of JavaScript. So, of course the underlaying Layer (JavaScript) can be passed through the layers to the top (TypeScript), but not the other way around.
Why not?
Think of it as a bike (JavaScript) and a motorcycle (TypeScript). The basics are the same (two wheels, a frame), but the motorcycle as an engine and some enhanced features.
So, you can use your motorcycle (TypeScript) as a bike (JavaScript), but you cannot use a bike as a motorcycle.
EDIT:
If your compiler throws a warning, why does it make the
statement wrong? It just says: Hey, you are using TypeScript, and it's
more strict than what you gave me.
See this example, it compiles perfectly to JavaScript, but throws a warning.

Test parse errors in intern do not include the line that describes the error

tl;dr When there is an error with a test written in intern I don't seem to get error messages that describe on which line the error occurred. I've found a workaround but its not really the ideal solution as it involves messing with code in dependent projects. Does any one have a better way / am I just doing it wrong? Thanks!
Details :
I've seen several times that when there is an issue with parsing a test written in intern (for example failing to close brackets, quotes etc.) that the actual line where the error occurred is not reported, and there is only an error like this (I've subbed in for the actual path as its a work project, but you get the gist):
SyntaxError: Unexpected identifier
at Function.vm.runInThisContext (<myproject>/node_modules/intern/node_modules/istanbul/lib/hook.js:163:16)
at <myproject>/node_modules/intern/node_modules/dojo/dojo.js:745:8
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
I poked around a little and discovered that there's an undocumented(? - its not in here) parameter for vm.runInThisContext, which if enabled actually provides details of the original error (here and here) - there's some discussion about how this will play out but if I switch dojo.js and hook.js in istanbul (if its running) to use this parameter, I get error messages like this :
<myproject>/test/publisherConfigSpec.js:16
errorCb cat = dfd.rejectOnError(function(error) {
^^^
SyntaxError: Unexpected identifier
at Function.vm.runInThisContext (<myproject>/node_modules/intern/node_modules/istanbul/lib/hook.js:163:16)
at <myproject>/node_modules/intern/node_modules/dojo/dojo.js:745:8
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
which is the output I want (or at least massively improves my chances of finding and fixing the error) but its not ideal to be messing about with the node dependencies, and it seems to me that it may be too much in flux for a pull request (see most recent update to the API) Is there an alternative way of getting useful output when there's an error parsing the test code input?
Thanks for any advice :)

The output that Node.js provides for SyntaxError is obviously not great, but we probably won’t use undocumented features (they’re undocumented for a reason!) in any official release of Intern to make it work differently. Non-syntax errors (runtime errors) will be caught and reported competently by Intern to whatever reporters you are using.
In this case, I’d advise you to use an editor that includes support for syntax checking: Komodo Edit/IDE, WebStorm, SublimeText, Eclipse, vim… if you get to the point where you are trying to run syntactically invalid code, your code editor is failing you by not telling you soon enough that you’ve made a mistake.