Update links to use https:// where it is supported. There's probably a lot
more that could be fixed, but these are the core ones I found (especially
the download links in order to prevent MITM attacks). Note that there are
some fb.me links that will redirect to http:// even while accessed over
https://, but this seemed like the best way to fix those for now.
NOTE: Only non-third-party files were modified. There are references to
http:// URLs in vendored/third-party files, but seems appropriate to fix
upstream for those rather than editing the files.
Also, copy one image locally to the blog, as it was hotlinking to a site
that did not support https://.
Last, use youtube-nocookie.com instead of youtube.com for video embeds,
as the former doesn't try to set a cookie on load (privacy enhancement).
Eslint now allows us to use a different parser, which allows us to use
esprima-fb explicitly. This means we don't have to wait for espree to add
things like rest-param parsing. Though we do need eslint to upgrade its rules
to handle that AST.
I had hoped to enable parsing of our tests but we can't do that until we
change esprima-fb's XJS nodes to JSX.
While I was here, I also enabled the no-unused-vars rule since eslint
understands template strings. I also made the single quote enforcement
actually fail instead of just warn.
In 1.4.0 we can use the TypeScript API directly to preprocess our files.
This lets us get rid of a dependency.
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API
We can also use this to provide our default libraries so that we don't
need to keep the references in the test file.
This is to make sure we don't end up with differences in our different
testing methods. We may switch out the failure allowances later (maybe
just jest will be good enough and we can let phantom fail for a little
bit).
As part of the new class effort it is now possible to define React
Components using any type of generic JavaScript class syntax.
This includes TypeScript classes. This test ensures that we don't regress
that support, and also serves as an example for using React in TypeScript.
TypeScript provides a good demo of where we think property initializers
are going.
We don't have any official *type* support for TypeScript yet.
This test trails the ReactES6Class-test file. Some manual tweaking is
required when converting tests.
As part of the new class effort it is now possible to define React
Components using any type of generic JavaScript class syntax.
This includes CoffeeScript. This test ensures that we don't regress that
support, and also serves as an example for using React in CoffeeScript.
This test fail trails the ReactES6Class-test file. Some manual tweaking is
required when converting tests.
These rules are very close to what we have internally. We may still miss
a couple things (jsdoc params being a big one) but it's good enough.
This is also more restrictive than what we enforce internally, but it's
for the best.
I dropped the part of constants.js that we weren't using (namely the
part where we insert constants) but left it open to do that. It should
be trivial, we just aren't using it.
Fixes#1824
Ben Alpert