{
  "_args": [
    [
      {
        "raw": "js-tokens@^3.0.0",
        "scope": null,
        "escapedName": "js-tokens",
        "name": "js-tokens",
        "rawSpec": "^3.0.0",
        "spec": ">=3.0.0 <4.0.0",
        "type": "range"
      },
      "/home/jdaugherty/work/GT2/GT2-Android/node_modules/loose-envify"
    ]
  ],
  "_from": "js-tokens@>=3.0.0 <4.0.0",
  "_id": "js-tokens@3.0.2",
  "_inCache": true,
  "_location": "/js-tokens",
  "_nodeVersion": "7.10.0",
  "_npmOperationalInternal": {
    "host": "s3://npm-registry-packages",
    "tmp": "tmp/js-tokens-3.0.2.tgz_1498683256536_0.7391157897654921"
  },
  "_npmUser": {
    "name": "lydell",
    "email": "simon.lydell@gmail.com"
  },
  "_npmVersion": "4.2.0",
  "_phantomChildren": {},
  "_requested": {
    "raw": "js-tokens@^3.0.0",
    "scope": null,
    "escapedName": "js-tokens",
    "name": "js-tokens",
    "rawSpec": "^3.0.0",
    "spec": ">=3.0.0 <4.0.0",
    "type": "range"
  },
  "_requiredBy": [
    "/loose-envify"
  ],
  "_resolved": "https://registry.npmjs.org/js-tokens/-/js-tokens-3.0.2.tgz",
  "_shasum": "9866df395102130e38f7f996bceb65443209c25b",
  "_shrinkwrap": null,
  "_spec": "js-tokens@^3.0.0",
  "_where": "/home/jdaugherty/work/GT2/GT2-Android/node_modules/loose-envify",
  "author": {
    "name": "Simon Lydell"
  },
  "bugs": {
    "url": "https://github.com/lydell/js-tokens/issues"
  },
  "dependencies": {},
  "description": "A regex that tokenizes JavaScript.",
  "devDependencies": {
    "coffee-script": "~1.12.6",
    "esprima": "^4.0.0",
    "everything.js": "^1.0.3",
    "mocha": "^3.4.2"
  },
  "directories": {},
  "dist": {
    "shasum": "9866df395102130e38f7f996bceb65443209c25b",
    "tarball": "https://registry.npmjs.org/js-tokens/-/js-tokens-3.0.2.tgz"
  },
  "files": [
    "index.js"
  ],
  "gitHead": "8315904c840b14d28de1b0a4968194555f61bea3",
  "homepage": "https://github.com/lydell/js-tokens#readme",
  "keywords": [
    "JavaScript",
    "js",
    "token",
    "tokenize",
    "regex"
  ],
  "license": "MIT",
  "maintainers": [
    {
      "name": "lydell",
      "email": "simon.lydell@gmail.com"
    }
  ],
  "name": "js-tokens",
  "optionalDependencies": {},
  "readme": "Overview [![Build Status](https://travis-ci.org/lydell/js-tokens.svg?branch=master)](https://travis-ci.org/lydell/js-tokens)\n========\n\nA regex that tokenizes JavaScript.\n\n```js\nvar jsTokens = require(\"js-tokens\").default\n\nvar jsString = \"var foo=opts.foo;\\n...\"\n\njsString.match(jsTokens)\n// [\"var\", \" \", \"foo\", \"=\", \"opts\", \".\", \"foo\", \";\", \"\\n\", ...]\n```\n\n\nInstallation\n============\n\n`npm install js-tokens`\n\n```js\nimport jsTokens from \"js-tokens\"\n// or:\nvar jsTokens = require(\"js-tokens\").default\n```\n\n\nUsage\n=====\n\n### `jsTokens` ###\n\nA regex with the `g` flag that matches JavaScript tokens.\n\nThe regex _always_ matches, even invalid JavaScript and the empty string.\n\nThe next match is always directly after the previous.\n\n### `var token = matchToToken(match)` ###\n\n```js\nimport {matchToToken} from \"js-tokens\"\n// or:\nvar matchToToken = require(\"js-tokens\").matchToToken\n```\n\nTakes a `match` returned by `jsTokens.exec(string)`, and returns a `{type:\nString, value: String}` object. The following types are available:\n\n- string\n- comment\n- regex\n- number\n- name\n- punctuator\n- whitespace\n- invalid\n\nMulti-line comments and strings also have a `closed` property indicating if the\ntoken was closed or not (see below).\n\nComments and strings both come in several flavors. To distinguish them, check if\nthe token starts with `//`, `/*`, `'`, `\"` or `` ` ``.\n\nNames are ECMAScript IdentifierNames, that is, including both identifiers and\nkeywords. You may use [is-keyword-js] to tell them apart.\n\nWhitespace includes both line terminators and other whitespace.\n\n[is-keyword-js]: https://github.com/crissdev/is-keyword-js\n\n\nECMAScript support\n==================\n\nThe intention is to always support the latest stable ECMAScript version.\n\nIf adding support for a newer version requires changes, a new version with a\nmajor verion bump will be released.\n\nCurrently, [ECMAScript 2017] is supported.\n\n[ECMAScript 2017]: https://www.ecma-international.org/ecma-262/8.0/index.html\n\n\nInvalid code handling\n=====================\n\nUnterminated strings are still matched as strings. JavaScript strings cannot\ncontain (unescaped) newlines, so unterminated strings simply end at the end of\nthe line. Unterminated template strings can contain unescaped newlines, though,\nso they go on to the end of input.\n\nUnterminated multi-line comments are also still matched as comments. They\nsimply go on to the end of the input.\n\nUnterminated regex literals are likely matched as division and whatever is\ninside the regex.\n\nInvalid ASCII characters have their own capturing group.\n\nInvalid non-ASCII characters are treated as names, to simplify the matching of\nnames (except unicode spaces which are treated as whitespace).\n\nRegex literals may contain invalid regex syntax. They are still matched as\nregex literals. They may also contain repeated regex flags, to keep the regex\nsimple.\n\nStrings may contain invalid escape sequences.\n\n\nLimitations\n===========\n\nTokenizing JavaScript using regexes—in fact, _one single regex_—won’t be\nperfect. But that’s not the point either.\n\nYou may compare jsTokens with [esprima] by using `esprima-compare.js`.\nSee `npm run esprima-compare`!\n\n[esprima]: http://esprima.org/\n\n### Template string interpolation ###\n\nTemplate strings are matched as single tokens, from the starting `` ` `` to the\nending `` ` ``, including interpolations (whose tokens are not matched\nindividually).\n\nMatching template string interpolations requires recursive balancing of `{` and\n`}`—something that JavaScript regexes cannot do. Only one level of nesting is\nsupported.\n\n### Division and regex literals collision ###\n\nConsider this example:\n\n```js\nvar g = 9.82\nvar number = bar / 2/g\n\nvar regex = / 2/g\n```\n\nA human can easily understand that in the `number` line we’re dealing with\ndivision, and in the `regex` line we’re dealing with a regex literal. How come?\nBecause humans can look at the whole code to put the `/` characters in context.\nA JavaScript regex cannot. It only sees forwards.\n\nWhen the `jsTokens` regex scans throught the above, it will see the following\nat the end of both the `number` and `regex` rows:\n\n```js\n/ 2/g\n```\n\nIt is then impossible to know if that is a regex literal, or part of an\nexpression dealing with division.\n\nHere is a similar case:\n\n```js\nfoo /= 2/g\nfoo(/= 2/g)\n```\n\nThe first line divides the `foo` variable with `2/g`. The second line calls the\n`foo` function with the regex literal `/= 2/g`. Again, since `jsTokens` only\nsees forwards, it cannot tell the two cases apart.\n\nThere are some cases where we _can_ tell division and regex literals apart,\nthough.\n\nFirst off, we have the simple cases where there’s only one slash in the line:\n\n```js\nvar foo = 2/g\nfoo /= 2\n```\n\nRegex literals cannot contain newlines, so the above cases are correctly\nidentified as division. Things are only problematic when there are more than\none non-comment slash in a single line.\n\nSecondly, not every character is a valid regex flag.\n\n```js\nvar number = bar / 2/e\n```\n\nThe above example is also correctly identified as division, because `e` is not a\nvalid regex flag. I initially wanted to future-proof by allowing `[a-zA-Z]*`\n(any letter) as flags, but it is not worth it since it increases the amount of\nambigous cases. So only the standard `g`, `m`, `i`, `y` and `u` flags are\nallowed. This means that the above example will be identified as division as\nlong as you don’t rename the `e` variable to some permutation of `gmiyu` 1 to 5\ncharacters long.\n\nLastly, we can look _forward_ for information.\n\n- If the token following what looks like a regex literal is not valid after a\n  regex literal, but is valid in a division expression, then the regex literal\n  is treated as division instead. For example, a flagless regex cannot be\n  followed by a string, number or name, but all of those three can be the\n  denominator of a division.\n- Generally, if what looks like a regex literal is followed by an operator, the\n  regex literal is treated as division instead. This is because regexes are\n  seldomly used with operators (such as `+`, `*`, `&&` and `==`), but division\n  could likely be part of such an expression.\n\nPlease consult the regex source and the test cases for precise information on\nwhen regex or division is matched (should you need to know). In short, you\ncould sum it up as:\n\nIf the end of a statement looks like a regex literal (even if it isn’t), it\nwill be treated as one. Otherwise it should work as expected (if you write sane\ncode).\n\n\nLicense\n=======\n\n[MIT](LICENSE).\n",
  "readmeFilename": "README.md",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/lydell/js-tokens.git"
  },
  "scripts": {
    "build": "node generate-index.js",
    "dev": "npm run build && npm test",
    "esprima-compare": "node esprima-compare ./index.js everything.js/es5.js",
    "test": "mocha --ui tdd"
  },
  "version": "3.0.2"
}