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

Reimplement missing code from jshint.js #2

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Reimplement missing code from jshint.js #2

wants to merge 4 commits into from

Conversation

ajakaja
Copy link

@ajakaja ajakaja commented Dec 10, 2018

Hey,

Got everything working, more or less, though I was gaining understanding of the API as I went so there are definitely some misunderstandings still in there. But all the tests passed!

(Well -- the test-262 tests did not run; I think they're broken in this branch. Haven't looked into it yet.)

@ajakaja ajakaja changed the title Reimplement excised code from jshint.js Reimplement missing code from jshint.js Dec 10, 2018
src/jshint.js Show resolved Hide resolved
src/jshint.js Outdated Show resolved Hide resolved
Copy link
Owner

@jugglinmike jugglinmike left a comment

Choose a reason for hiding this comment

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

Hey Alex,

This is great work! I think it's almost ready for upstream. Here's how I'd like to move forward:

I like all of your ideas for future improvements, and I admire your restraint in not implementing them right now. That said, we generally prefer to document plans for future work using the project issue tracker. I'd like to wait a bit before directing you to contribute to the upstream codebase directly, so in the mean time, I've filed a couple issues against this project: gh-3 and gh-4 (I've also reported those in the upstream repository). If you'd like to take them on, I would gladly accept the patches here and re-land them upstream. In any event, would you mind removing the "TODO"s from this patch?

Separately, the patch currently fails the project's linting checks as reported by the command npm test (or npm run pretest). Would you mind fixing those?

With those things out of the way, here's how I'd like to merge your work (I don't expect you to do this part, but I still want to make sure it's okay with you). We've set out to re-implement existing functionality, and that makes me sensitive to the potential for regression. As you know, that's a risk I'm willing to take, but we should do our best to mitigate it. You've done your part by getting the tests to pass and documenting your process. For my part, I'd like to be particularly precise with how it gets merged. I'm going to land it as three distinct commits:

  • typo corrections
  • implementation of the missing functionality
  • enhancement of the test harness

My hope is that will help demonstrate the equivalency of your implementation without losing any of the other improvements you've contributed. Does that sound okay with you?

src/jshint.js Outdated
advance();
if (state.tokens.next.value === "{") {
// manually cheating the test "invalidClasses", which asserts this particular behavior when a class is misdefined.
// this is completely ridiculous, but I don't want to change any tests right now.
Copy link
Owner

Choose a reason for hiding this comment

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

Impressive!

src/jshint.js Outdated
// so I'm just saving it on the state directly.
// state.inObjectBody is distinct from state.inClassBody because .inClassBody also causes strict mode to be used, which is
// not correct for object literals.
if (!state.inClassBody && !state.inObjectBody && !isMethod()) {
Copy link
Owner

Choose a reason for hiding this comment

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

Your suspicion of state.inClassBody is well-founded. However, I'm willing to accept this because the existing state.inObjectBody sets a clear precedent for this and because the ways it fails are fairly specific. I'm happy to to improve the general pattern shared by both flags myself.

src/jshint.js Outdated
className = classNameToken.value;
}

//TODO: the constructor's 'name' should be the name of the variable in an assignment expression, ie in 'var x = class Y {}' I believe it's supposed to be 'x'.
Copy link
Owner

Choose a reason for hiding this comment

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

This is a lot like a question someone asked on the blog post you found!

What would the name be of the following: var myVar = function myFunc(){};

In your example, the name would be "Y". V8 (and SpiderMonkey) get this right:

$ node -p 'var x = class Y {}; x.name'
Y

src/jshint.js Outdated
advance();
break;
case "constructor":
if (isStatic || inGenerator) {
Copy link
Owner

Choose a reason for hiding this comment

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

Actually, static methods may be named "constructor", so (confusing though it may be) we'll need to allow that.

@ajakaja
Copy link
Author

ajakaja commented Dec 17, 2018

That all sounds good. I will remove TODOs and -- whoops, I was using 'test-all' to run the tests and forgot to run 'test' again to check for the linter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants