JSX linting fails due to espree minor release including major dependency bump

[debugwand]

Espree has released a minor version 4.1.0 which bumps acorn-jsx to a new major version (5), which in turn breaks JSX linting (see eslint/espree#393)

Acorn-jsx needs to be used in a different way as of version 5,
acornjs/acorn-jsx@ddcc01d

We are running command eslint **/*.jsx in the terminal, errors thrown:
error Parsing error: Unexpected token =

ESLint: 5.7.0
Node: any
npm: any

Configuration

module.exports = {
	env: {
		node: true,
		browser: true,
		es6: true
	},
	plugins: [
		'jsx-a11y'
	],
	extends: [
		'eslint:recommended',
		// https://github.com/jest-community/eslint-plugin-jest
		'plugin:jest/recommended',
		// https://github.com/yannickcr/eslint-plugin-react
		'plugin:react/recommended',
		// https://github.com/evcohen/eslint-plugin-jsx-a11y
		'plugin:jsx-a11y/recommended'
	],
	parserOptions: {
		ecmaFeatures: {
			jsx: true
		},
		ecmaVersion: 2018,
		// Support for ESM is not tied to an ES version
		sourceType: 'module'
	},
	settings: {
		react: {
			version: '16.3'
		}
	},
	rules: {
		// We don't expect consumers of x-dash to use prop types
		'react/prop-types': 'off',
		// We don't use display names for SFCs
		'react/display-name': 'off',
		// This rule is intended to catch < or > but it's too eager
		'react/no-unescaped-entities': 'off'
	},
	overrides: [
		{
			// Components in x-dash interact with x-engine rather than React
			files: [ 'components/**/*.jsx' ],
			settings: {
				react: {
					pragma: 'h',
					createClass: 'Component'
				}
			},
			rules: {
				'react/prefer-stateless-function': 'error'
			}
		}
	]
};

[not-an-aardvark]

Hi, thanks for the report. Could you provide an example of a source file that fails to parse? JSX parsing in general seems to be working for me using the latest version of espree. It's possible that there is a bug here, but as far as I can tell it doesn't seem to apply to all JSX code, so it would be helpful to have a reproducible example.

[not-an-aardvark]

Based on the discussion in eslint/espree#393, it seems like this might be the result of a bug in npm.

[sholladay]

I am also experiencing this. Getting a lot of crazy parse errors on JSX files that have not changed since the last time CI passed, while plain old JS files seem to be unaffected.

One thing to note about my setup is I am using ESLint via XO. Interestingly, I wasn't able to quickly reproduce with a global XO or global ESLint install, only the local one in my project (even after refreshing node_modules). ESLint and its dependencies seem to be the only ones with a new release this month.

$ npm ls acorn-jsx
└─┬ xo@0.23.0
  └─┬ eslint@5.7.0
    └─┬ espree@4.1.0
      └── acorn-jsx@5.0.0

The most basic JSX syntax is failing to parse.

const broken = () => {
    return <p>I should parse correctly</p>;	
};

$ xo lib/components/foo.jsx
lib/components/foo.jsx:2:40
  ✖  2:40  Parsing error: Unexpected token /

[sholladay]

Took a long time, but I managed to narrow this down to something interesting. The parsing error stops happening if I remove browser-env from my dependencies.

Using the same simple source file I posted earlier and running with npx xo...

Working

{
    "name": "eslint-bug-repro",
    "version": "0.0.1",
    "homepage": "https://github.com/sholladay",
    "main": "index.js",
    "author": {
        "name": "Seth Holladay",
        "url": "https://seth-holladay.com"
    },
    "license": "MPL-2.0",
    "devDependencies": {
        "xo": "^0.23.0"
    }
}

Broken

{
    "name": "eslint-bug-repro",
    "version": "0.0.1",
    "homepage": "https://github.com/sholladay",
    "main": "index.js",
    "author": {
        "name": "Seth Holladay",
        "url": "https://seth-holladay.com"
    },
    "license": "MPL-2.0",
    "devDependencies": {
        "browser-env": "^3.2.5",
        "xo": "^0.23.0"
    }
}

Since XO has a cache, it's a good idea to run this in between:

rm -rf ~/.xo-cache package-lock.json node_modules

Definitely feels like some sort of npm issue.

[mysticatea]

So this is a bug in npm.

npm doesn't seem to install dependencies correctly if a package which has a name before eslint in the alphabet order and has old acorn in that dependencies exists.... The acorn that espree depends on is lost. It hoists acorn-jsx to node_modules/ but pins acorn on node_modules/espree/node_modules/. As the result, the acorn-jsx imports a wrong version of acorn.

[mysticatea]

I reported: https://npm.community/t/failed-to-install-eslint-in-a-specific-situation/2975

[ibc]

Hi, I've two projects A and B, both with same subset and config of react+babel+eslint. Not sure if relevant, but:

• In project A the issue above happens to me after upgrading from eslint 5.7.0 to eslint 5.8.0, but it also happens if I later downgrade it to 5.7.0. I also upgraded these deps:

 react-responsive  ^5.0.0  →         ^6.0.0
 randomatic         ^3.1.0  →   ^3.1.1
 react             ^16.5.2  →  ^16.6.0
 react-dom         ^16.5.2  →  ^16.6.0
 react-image-crop   ^6.0.0  →   ^6.0.4
 react-redux        ^5.0.7  →   ^5.1.0
 ansi-colors        ^3.1.0  →   ^3.2.1
 eslint             ^5.7.0  →   ^5.8.0

• In project B, even upgrading to eslint 5.8.0, I don't get the error. Those are my updates in B:

 react        ^16.5.2  →  ^16.6.0
 react-dom    ^16.5.2  →  ^16.6.0
 react-redux   ^5.0.7  →   ^5.1.0
 eslint        ^5.7.0  →   ^5.8.0

• In A:

$ npm ls acorn-jsx
myProjectA
└─┬ eslint@5.8.0
  └─┬ espree@4.1.0
    └── acorn-jsx@5.0.0

• In B:

$ npm ls acorn-jsx
myProjectB
├─┬ eslint@5.8.0
│ └─┬ espree@4.0.0
│   └── acorn-jsx@4.1.1
└─┬ web-ext@2.9.1
  └─┬ addons-linter@1.3.1
    └─┬ eslint-plugin-no-unsafe-innerhtml@1.0.16
      └─┬ eslint@3.19.0
        └─┬ espree@3.5.4
          └── acorn-jsx@3.0.1

I've deleted node_modules and package-lock.json before upgrading.

[herodrigues]

I also got weird lint errors after upgrading eslint to v5.8.0

error  Parsing error: Unexpected token =

Deleting node_modules and package-lock.json, then installing all packages again solved the issue.

[ibc]

Confirmed that I got rid of those errors by also removing node_modules and package-lock.json. It seems that, previously, I did not delete the lock file.

[nzakas]

@mysticatea @not-an-aardvark has this been addressed now or are we still waiting for an npm fix?

[ljharb]

Since this happens in eslint 5.8 but not 5.7, perhaps whatever changed to surface the npm bug should be reverted and shipped in a patch release?

[mysticatea]

I don't think the revert makes sense. This causes by acorn's breaking change. Currently, the npm's bug appears when there is a older acorn in another dependency. After reverting, it will appear when there is a newer acorn in another dependency.

I had emailed with the npm support and they said they will discuss about this bug in npm inc.

But my request (please share the current status on https://npm.community/t/failed-to-install-eslint-in-a-specific-situation/2975) was ignored or they have no progress.

[mysticatea]

The npm support team told me: "the bug fix requires substantial architectural changes, as a result, it's on our roadmap for 2019 and might be implemented in the summer."

Probably, it's the following item in the roadmap:

Two-pass installer where resolution of the logical tree is distinct from computing the physical tree. With this we may be able to, at long last, end the pain around peerDependencies.
https://blog.npmjs.org/post/173239798780/beyond-npm6-the-future-of-the-npm-cli