babel: Template string failing with Cannot read property 'range' of null

FYI; This is still broken.

package versions eslint@7.13.0 @babel/eslint-parser@7.12.1

Have to selectively disable ESLint rules to skirt the problem, like so:

"template-curly-spacing" : "off"

or ESLint still blows up with:

TypeError: Cannot read property 'value' of null
Occurred while linting [redacted]
    at checkSpacingBefore ([redacted]\node_modules\eslint\lib\rules\template-curly-spacing.js:52:24)
    at TemplateElement ([redacted]\node_modules\eslint\lib\rules\template-curly-spacing.js:136:17)
    at [redacted]\node_modules\eslint\lib\linter\safe-emitter.js:45:58
    at Array.forEach (<anonymous>)
    at Object.emit ([redacted]\node_modules\eslint\lib\linter\safe-emitter.js:45:38)
    at NodeEventGenerator.applySelector ([redacted]\node_modules\eslint\lib\linter\node-event-generator.js:254:26)
    at NodeEventGenerator.applySelectors ([redacted]\node_modules\eslint\lib\linter\node-event-generator.js:283:22)
    at NodeEventGenerator.enterNode ([redacted]\node_modules\eslint\lib\linter\node-event-generator.js:297:14)
    at CodePathAnalyzer.enterNode ([redacted]\node_modules\eslint\lib\linter\code-path-analysis\code-path-analyzer.js:711:23)
    at [redacted]\node_modules\eslint\lib\linter\linter.js:952:32

Here, inside template-curly-spacing the sourceCode.getFirstToken call ends up returning null:

return {
  TemplateElement(node) {
    const token = sourceCode.getFirstToken(node);

    checkSpacingBefore(token);
    checkSpacingAfter(token);
  }
};

[EDIT]

Looks like this is STILL the problem with a wrong version of @babel/types being used. After a thorough wipe and reinstall of all things @babel (as npm dedup was deduping to the WRONG version) it does work.

I though the whole idea of having the eslint parser go into the mono repo was to maintain it together with Babel and prevent exactly that shitty issue?

Fixed in @babel/eslint-parser@7.11.3.

This should be fixed in the latest v11 prerelease (and will be included in the next major release, which will be under a new package name).

How should fix, upgrading packages?? or Should wait some new release? I upgrade to @babel/eslint-parser@7.11.3 but I still have these problem. Thanks !

use @babel/eslint-parser, because

I found this minimum configuration helpful (with unrelated or too specific pieces removed):

package.json

{
	"name": "your-project",
	"devDependencies": {
		"@babel/core": "^7.11.6",
		"@babel/eslint-parser": "^7.11.5",
		"@babel/eslint-plugin": "^7.11.5",
		"@babel/preset-env": "^7.11.5",
		"eslint": "^7.9.0"
	}
}

.babelrc (required)

{
	"presets": [
		[
			"@babel/env",
			{
				"targets": {
					"edge": "17",
					"firefox": "60",
					"chrome": "67",
					"safari": "11.1"
				},
				"useBuiltIns": "usage",
				"corejs": "3.6.4"
			}
		]
	]
}

.eslintrc

{
	"plugins": [
		"@babel"
	],
	"extends": [
		"your-preferred-ruleset-here"
	],
	"parser": "@babel/eslint-parser",
}

Fixed with https://github.com/atlassian/yarn-deduplicate apparently in my case one package messes up dependency tree.

Thanks @LexSwed, It seems that was the problem in my case as well. I needed to run yarn-deduplicate yarn.lock after installing @babel/eslint-parser@7.11.3 to get it to work.

“babel-eslint”: “10.1.0” OR “@babel/eslint-parser”: “^7.11.0”, “eslint”: “7.6.0”,

The babel-eslint parser can be used by eslint to allow it to parse JS code using babel plugins which are in proposal stage.

I ran in to this particular issue with babel-eslint when it tried to parse the following code with optional chaining:

  this.x?.y(`template ${z}`);

The eslint doesn’t throw the error if the optional chaining is removed from ☝️.

A log at https://github.com/babel/babel-eslint/blob/10.x/lib/babylon-to-espree/toAST.js#L101 or https://github.com/babel/babel/blob/master/eslint/babel-eslint-parser/src/convert/convertAST.js#L64 to log the node object shows that the following node is missing when optional chaining is present.

Node {
  type: 'TemplateLiteral',
  start: 9583,
  end: 9650,
  loc:
   SourceLocation {
     start: Position { line: 254, column: 10 },
     end: Position { line: 254, column: 77 } },
  range: [ 9583, 9650 ],
  expressions:
   [ Node {
       type: 'MemberExpression',
       start: 9626,
       end: 9647,
       loc: [SourceLocation],
       range: [Array],
       object: [Node],
       property: [Node],
       computed: false,
       optional: false,
       _babelType: 'MemberExpression' } ],
  quasis:
   [ Node {
       type: 'TemplateElement',
       start: 9584,
       end: 9624,
       loc: [SourceLocation],
       range: [Array],
       value: [Object],
       tail: false,
       _babelType: 'TemplateElement' },
     Node {
       type: 'TemplateElement',
       start: 9648,
       end: 9649,
       loc: [SourceLocation],
       range: [Array],
       value: [Object],
       tail: true,
       _babelType: 'TemplateElement' } ],
  _babelType: 'TemplateLiteral' }

I believe that these nodes are generated by the “@babel/parser” library. Is it possible that the issue is in the parser lib?

when will this release? use 8.x babel-eslint will result in other bugs…

Try switching to @babel/eslint-parser.

With the next iteration of babel-eslint, we have decided to publish the package under a new name: @babel/eslint-parser.

https://babeljs.io/blog/2020/07/13/the-state-of-babel-eslint

@EarthyOrange Thanks for digging into this! I’ll look into this with this new information (though if you want to continue investigating, feel free). This could be a bug in @babel/parser’s logic (most likely in the estree plugin) or it could be a bug in @babel/eslint-parser, which serves as the compatibility layer between ESLint and Babel (and does perform some mutations of the AST).