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

Version 2.13.0 #3486

Merged
merged 20 commits into from May 30, 2021
Merged

Version 2.13.0 #3486

merged 20 commits into from May 30, 2021

Conversation

@jugglinmike
Copy link
Member

@jugglinmike jugglinmike commented Jun 20, 2020

This is a tracking branch for the next minor release of JSHint. If you'd like
to implement a new feature, this is the place to submit it!

ES2020 features:

@coveralls
Copy link

@coveralls coveralls commented Jun 20, 2020

Coverage Status

Coverage remained the same at 100.0% when pulling 6bfcaed on v2.12.0 into f05c8d1 on master.

@jugglinmike jugglinmike force-pushed the v2.12.0 branch from 274a462 to 067aad1 Jun 21, 2020
@jugglinmike
Copy link
Member Author

@jugglinmike jugglinmike commented Jul 2, 2020

I've updated the description with a list of ES2020 features that are relevant for JSHint.

@jugglinmike jugglinmike changed the title Version 2.12.0 Version 2.13.0 Aug 16, 2020
@jugglinmike
Copy link
Member Author

@jugglinmike jugglinmike commented Aug 16, 2020

We published the project license change using version 2.12.0, so I'm updating this pull request to describe 2.13.0 instead.

@jugglinmike jugglinmike force-pushed the v2.12.0 branch from 836df69 to 8763239 Sep 19, 2020
@jugglinmike
Copy link
Member Author

@jugglinmike jugglinmike commented Sep 19, 2020

Rebased on top of the master branch

jugglinmike added 13 commits Jun 20, 2020
This commit extends the options parsing system to tolerate the values
"11" and "2020" for the `esversion` linting option. It does not
introduce support for any features introduced by the new edition of the
language.
No call site for `propertyName` specifies an object value for the second
argument. The `optionalidentifier` function returns only string values
or undefined. These two invariants make the untested code paths
unreachable. Remove them both.
In so-called "object short notation," an IdentifierName is interpreted
as both a LiteralPropertyName and an IdentifierReference. The second is
a more restrictive goal than the first, so it is not necessary to apply
the LiteralPropertyName validation rules. Removing that validation logic
allows for an otherwise-unused parameter of the internal `propertyName`
function to be removed.
Extend consideration to include bindings created using
DestructuringBindingPattern.
Currently, the `setExported` method only makes the specified binding as
"used." This is unnecessary in this context because when `expression`
processes an IdentifierReference, it does the same. Remove the branch.
jugglinmike added 6 commits Oct 5, 2020
The situation described by this condition does not constitute
syntactically invalid code, so it should be reported with a warning.
Add an internal test so the coverage analysis tool recognizes that the
modified branch is verified.
Tolerate parsing errors regarding escape sequences in IdentifierNames as
these reflect a pre-existing deficiency which will require a dedicated
patch to correct.
@jugglinmike jugglinmike force-pushed the v2.12.0 branch from 59028b0 to b125dbe Mar 1, 2021
@jugglinmike
Copy link
Member Author

@jugglinmike jugglinmike commented Mar 1, 2021

We've landed a bunch of bug fixes to the master branch, particularly ones that will help implement dynamic import in this branch. Although traditional git workflows would call for merging master into this feature branch, I've chosen to rebase. That keeps this history clean, and since no one else is working from this branch (to the best of my knowledge), there's little risk of disruption that's typical in rebase operations.

I've pushed the prior version of this branch to my fork of the repository in case that's helpful.

@RedGuy12
Copy link

@RedGuy12 RedGuy12 commented Mar 15, 2021

Any ETA?

What's on the TODO list other than dynamic import?

@almercier
Copy link

@almercier almercier commented Apr 22, 2021

@jugglinmike With dynamic import PR #3540 merged, is this ready to go out of draft now?

@jugglinmike
Copy link
Member Author

@jugglinmike jugglinmike commented Apr 26, 2021

@almercier Yes!

@rwaldron You've already reviewed everything in this branch, so no further action required here. That said, it would be nice to get gh-3541 in for the next release. Would you mind taking a look at that?

@jugglinmike jugglinmike marked this pull request as ready for review Apr 26, 2021
@shmolf
Copy link

@shmolf shmolf commented May 20, 2021

I'm very much looking forward to see this available in my development environment. Will this be approved and merged anytime soon, so as to make it into the next tagged version?

@almercier
Copy link

@almercier almercier commented May 25, 2021

@jugglinmike @rwaldron It's been about a month since any update on this, do you have an estimated timeline on when this could be released?

@jugglinmike jugglinmike merged commit 7c36c81 into master May 30, 2021
5 checks passed
5 checks passed
continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 100.0%
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants