Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eslint-module-utils: filePath in parserOptions #840

Merged
merged 8 commits into from
May 31, 2017

Conversation

sompylasar
Copy link
Contributor

Refs #839

@coveralls
Copy link

coveralls commented May 19, 2017

Coverage Status

Coverage increased (+0.003%) to 95.062% when pulling b4d75c8 on sompylasar:patch-2 into 1377f55 on benmosher:master.

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but it should have a regression test.

@sompylasar
Copy link
Contributor Author

@ljharb OK, will add, what specifically? Assert the path to be actually passed?

@ljharb
Copy link
Member

ljharb commented May 20, 2017

@sompylasar that's ideal, yes

@sompylasar
Copy link
Contributor Author

@ljharb

  1. I need a spy to intercept parser call in the test. I've implemented a naive one in 6 lines, but if you'd like to import a library like sinon or chai-spies instead, let me know.
  2. I've bumped the eslint-module-utils version to 2.1.0, added lines to both CHANGELOGs, and updated the eslint-plugin-import dependency version of eslint-module-utils.

@sompylasar
Copy link
Contributor Author

Now CI fail with No compatible version found: eslint-module-utils@^2.1.0, how do you update these versions? @ljharb

@@ -3,9 +3,13 @@ All notable changes to this module will be documented in this file.
This project adheres to [Semantic Versioning](http://semver.org/).
This change log adheres to standards from [Keep a CHANGELOG](http://keepachangelog.com).

## v2 - 2016-11-07
## v2.1.0 - 2017-05-20
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The version number and date aren't decided yet; If you want to call this section "Unreleased" that'd be helpful :-)

@@ -1,6 +1,6 @@
{
"name": "eslint-module-utils",
"version": "2.0.0",
"version": "2.1.0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please revert this; package.json should never be bumped in a PR - only in a commit directly made to master.

@ljharb
Copy link
Member

ljharb commented May 20, 2017

It'd have to be npm published - but that won't happen until after it's merged.

@sompylasar
Copy link
Contributor Author

@ljharb Reverted: 7712ce1

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd probably bring in sinon (more deps is a good thing), but this is fine for now.

@sompylasar
Copy link
Contributor Author

I'd probably bring in sinon (more deps is a good thing), but this is fine for now.

👍 I'm for sinon, too. I'd also use chai assert instead of expect (too much magic), but it was already there, so consistency...

@coveralls
Copy link

coveralls commented May 20, 2017

Coverage Status

Coverage increased (+0.05%) to 95.111% when pulling 7712ce1 on sompylasar:patch-2 into 1377f55 on benmosher:master.

Copy link
Member

@benmosher benmosher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The actual (one-liner) change LGTM 👍🏻

re: tests, I am mildly opposed to adding a handrolled spy to eslint-module-utils, mostly because it's out of scope for that package. Would rather have a dev-dep on the easiest thing to integrate with.

I'm cool with Sinon.

@sompylasar
Copy link
Contributor Author

@benmosher Updated, PTAL. Replaced hand-made spy with sinon.spy.

@coveralls
Copy link

coveralls commented May 26, 2017

Coverage Status

Coverage increased (+0.04%) to 95.097% when pulling 7ac5e8f on sompylasar:patch-2 into 2f690b4 on benmosher:master.

@coveralls
Copy link

coveralls commented May 26, 2017

Coverage Status

Coverage increased (+0.04%) to 95.097% when pulling 7ac5e8f on sompylasar:patch-2 into 2f690b4 on benmosher:master.

@coveralls
Copy link

coveralls commented May 26, 2017

Coverage Status

Coverage increased (+0.07%) to 95.125% when pulling d397b9b on sompylasar:patch-2 into 2f690b4 on benmosher:master.

it('passes expected parserOptions to custom parser', function () {
const parseSpy = sinon.spy()
const parserOptions = { ecmaFeatures: { jsx: true } }
require('./parseStubParser').parse = parseSpy
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

require has a cache, so you get the same value out of it every time - any reason this isn't required at the top level?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, can pull to top. Both this and resolve. Just a habit of having self-contained tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done: 5732742

@coveralls
Copy link

coveralls commented May 29, 2017

Coverage Status

Coverage increased (+0.07%) to 95.13% when pulling 5732742 on sompylasar:patch-2 into 2f690b4 on benmosher:master.

import parse from 'eslint-module-utils/parse'

import { getFilename } from '../utils'

describe('parse(content, { settings, ecmaFeatures })', function () {
const path = getFilename('jsx.js')
const parseStubParser = require('./parseStubParser')
const parseStubParserPath = require.resolve('./parseStubParser')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

requires should generally all only be static and at the top level of the file - can these be moved one level higher?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ljharb This require was left here like that on purpose, this is not just a dependency like any other, this is a stub which must be in a file that can be literally required because of the way eslint, and following it, eslint-import-resolver, resolves the parser function via require function (and we can do nothing about that).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ljharb For the same reason, the line above: const path = getFilename('jsx.js') could be moved up, but it's not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand, but this can stay where it is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, require('./parseStubParser') and require.resolve('./parseStubParser') should sit next to each other, they are closely related in this test.

@@ -22,6 +22,10 @@ exports.default = function parse(path, content, context) {
// always attach comments
parserOptions.attachComment = true

// provide the `filePath` like eslint itself does, in `parserOptions`
// https://github.com/eslint/eslint/blob/3ec436ee/lib/linter.js#L637
parserOptions.filePath = path
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps the path needs to be path.normalized?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. What is the error case? The serialized parserOptions participates in some cache key, right? Where is it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The internal parser has a cache that is a hash of the parse settings and the module path. So I'm guessing the path must be relative.

An absolute path would work, or the cache key could drop the file path key.

I am not at a computer right now but I think the cache access is in utils/resolve.js

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, not thinking -- relative would be fine as long as it's all against cwd. So maybe path.normalize would be fine

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the pointers, I'll look into that and suggest a change and tests when I get to my computer (afk, too).

sompylasar added a commit to sompylasar/eslint-plugin-import that referenced this pull request Jun 4, 2017
…h_in_parser_options

* commit '3c46d308ccb462a52554257c49c374045d1a6cf7':
  rollback utils dependency to 2.0.0
  add yank note to utils change log
  add yanking note to root change log
  Upgrade debug version of eslint-module-utils (import-js#844)
  remove obsolete dad joke
  update utils changelog
  bump eslint-module-utils to v2.1.0
  bump v2.4.0
  fix typos, enforce type of array of strings in allow option
  update CHANGELOG.md
  eslint-module-utils: filePath in parserOptions (import-js#840)
  write doc, add two more tests
  add allow glob for rule no-unassigned-import, fix import-js#671

# Conflicts:
#	utils/CHANGELOG.md
@sompylasar sompylasar mentioned this pull request Jun 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

4 participants