aboutsummaryrefslogtreecommitdiff
path: root/node_modules/js-tokens/README.md
diff options
context:
space:
mode:
authorFlorian Dold <florian.dold@gmail.com>2018-09-20 02:56:13 +0200
committerFlorian Dold <florian.dold@gmail.com>2018-09-20 02:56:13 +0200
commitbbff7403fbf46f9ad92240ac213df8d30ef31b64 (patch)
treec58400ec5124da1c7d56b01aea83309f80a56c3b /node_modules/js-tokens/README.md
parent003fb34971cf63466184351b4db5f7c67df4f444 (diff)
update packages
Diffstat (limited to 'node_modules/js-tokens/README.md')
-rw-r--r--node_modules/js-tokens/README.md32
1 files changed, 25 insertions, 7 deletions
diff --git a/node_modules/js-tokens/README.md b/node_modules/js-tokens/README.md
index 5c93a8885..00cdf1634 100644
--- a/node_modules/js-tokens/README.md
+++ b/node_modules/js-tokens/README.md
@@ -73,14 +73,13 @@ Whitespace includes both line terminators and other whitespace.
ECMAScript support
==================
-The intention is to always support the latest stable ECMAScript version.
+The intention is to always support the latest ECMAScript version whose feature
+set has been finalized.
If adding support for a newer version requires changes, a new version with a
major verion bump will be released.
-Currently, [ECMAScript 2017] is supported.
-
-[ECMAScript 2017]: https://www.ecma-international.org/ecma-262/8.0/index.html
+Currently, ECMAScript 2018 is supported.
Invalid code handling
@@ -100,7 +99,8 @@ inside the regex.
Invalid ASCII characters have their own capturing group.
Invalid non-ASCII characters are treated as names, to simplify the matching of
-names (except unicode spaces which are treated as whitespace).
+names (except unicode spaces which are treated as whitespace). Note: See also
+the [ES2018](#es2018) section.
Regex literals may contain invalid regex syntax. They are still matched as
regex literals. They may also contain repeated regex flags, to keep the regex
@@ -144,7 +144,8 @@ var regex = / 2/g
A human can easily understand that in the `number` line we’re dealing with
division, and in the `regex` line we’re dealing with a regex literal. How come?
Because humans can look at the whole code to put the `/` characters in context.
-A JavaScript regex cannot. It only sees forwards.
+A JavaScript regex cannot. It only sees forwards. (Well, ES2018 regexes can also
+look backwards. See the [ES2018](#es2018) section).
When the `jsTokens` regex scans throught the above, it will see the following
at the end of both the `number` and `regex` rows:
@@ -192,7 +193,7 @@ valid regex flag. I initially wanted to future-proof by allowing `[a-zA-Z]*`
(any letter) as flags, but it is not worth it since it increases the amount of
ambigous cases. So only the standard `g`, `m`, `i`, `y` and `u` flags are
allowed. This means that the above example will be identified as division as
-long as you don’t rename the `e` variable to some permutation of `gmiyu` 1 to 5
+long as you don’t rename the `e` variable to some permutation of `gmiyus` 1 to 6
characters long.
Lastly, we can look _forward_ for information.
@@ -215,6 +216,23 @@ If the end of a statement looks like a regex literal (even if it isn’t), it
will be treated as one. Otherwise it should work as expected (if you write sane
code).
+### ES2018 ###
+
+ES2018 added some nice regex improvements to the language.
+
+- [Unicode property escapes] should allow telling names and invalid non-ASCII
+ characters apart without blowing up the regex size.
+- [Lookbehind assertions] should allow matching telling division and regex
+ literals apart in more cases.
+- [Named capture groups] might simplify some things.
+
+These things would be nice to do, but are not critical. They probably have to
+wait until the oldest maintained Node.js LTS release supports those features.
+
+[Unicode property escapes]: http://2ality.com/2017/07/regexp-unicode-property-escapes.html
+[Lookbehind assertions]: http://2ality.com/2017/05/regexp-lookbehind-assertions.html
+[Named capture groups]: http://2ality.com/2017/05/regexp-named-capture-groups.html
+
License
=======