-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Attempt to clean things up some #4193
Conversation
I snipped out the relevant failed tests from the Travis log
|
It looks like there are a lot of unrelated automatic style changes in this PR. Don't you think the meaningful changes should be separated out from stylistic things to make this easier to assess? |
Hey there. So the goal here was to use StandardJS rules to make the code
more readable; and identify basic errors. The other major change was fixing
up the testing system to account for newer browsers & NodeJS. This allowed
for the creation of the bug report.
On May 4, 2018 4:48 PM, "Jeremy Ashkenas" <notifications@github.com> wrote:
It looks like there are a lot of unrelated automatic style changes in this
PR. Don't you think the meaningful changes should be separated out from
stylistic things to make this easier to assess?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4193 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA9fv1TGzGOG269_SVTA9IizxCaIwKkCks5tvOjHgaJpZM4TzYR1>
.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also suggest doing this in smaller chunks. Mainly though we should avoiding reverting every change since 1.3.3
bower.json
Outdated
@@ -2,7 +2,7 @@ | |||
"name" : "backbone", | |||
"main" : "backbone.js", | |||
"dependencies" : { | |||
"underscore" : ">=1.8.3" | |||
"underscore" : ">=1.9.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did something change that makes 1.8.3 not still valid?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know he updated Underscore recently, and there are still bugs over in that being looked at. I was just going over unit test code when you replied! (too tired to finish that up tonight)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does it matter if underscore was updated? Currently this lib support 1.8.3 and 1.9.x etc.. upping this to 1.9.0 removes support for 1.8.3 unnecessarily. Unless you've used something from 1.9 that isn't in 1.8.3?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, if the rule before was ^1.8.3, it's gonna go to 1.9.0 anyway on an npm install.
I need sleep. I can go over this stuff later again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes but if your rule was 1.8.3 you are out of luck
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is also worth noting that backbone versions are not semver
package.json
Outdated
"doc": "docco backbone.js && docco examples/todos/todos.js examples/backbone.localStorage.js", | ||
"lint": "eslint backbone.js test/*.js" | ||
}, | ||
"main": "backbone.js", | ||
"version": "1.3.3", | ||
"version": "1.3.4", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's no reason to assume this would be 1.3.4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't want it getting confused with the current version.
backbone.js
Outdated
options || (options = {}); | ||
this.preinitialize.apply(this, arguments); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is removing all of the changes currently in master
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forked from master. What did I miss????
backbone.js
Outdated
return this; | ||
}, | ||
|
||
// Remove this view by taking the element out of the DOM, and removing any | ||
// applicable Backbone.Events listeners. | ||
remove: function() { | ||
remove: function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this rule should change. Linting is great, but there's no need to modify the current style if there is already a precedent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please edit the .eslintrc with the desired spec. My primary concern is bug-hunting, followed by figuring out how best to make sure this & underscore are working, so I know my efforts on floorplan aren't in vain.
@paulfalgout Good morning! I dunno if you saw it, but over the weekend I did try to address your concerns regarding the PR. I hope they helped. Sorry if I wasn't as compliant Friday night: I was exhausted. |
@jashkenas @paulfalgout Whether this particular PR gets rejected / reworked / whatnot; I do have interest in getting some of these libraries updated to ES2015+ syntax. I've had to crash-course getting up to speed on JS in the past few months; and this is right when Mozilla is finishing up some key ES2015+ support for public use this week. The app I've been working on is 5+ years old (pre-2015); and the things I've found in trying to make that work, appear to solve a lot of old problems. I view such effort not unlike office filing: tedious, but necessary. Babel & Browserfy also seem useful in allowing for the source to be ES2015+; but still have production builds that'll run on ES5 runtimes. |
@paulfalgout @jashkenas I'll close this PR & do a revised one as able. I figure you might appreciate one that has the unit testing cleaned up, but the base code "virgin" to be less disruptive? Due apologies for any trouble on all of this. |
Hey @jashkenas . I've been working on a ES5->ES2015 project conversion; and have stumbled into trying to cleanup & assure that the assorted dependencies are reliable. I already have a pull in with Mediator; I figured this should get some similar attention. If this works, maybe it could be the starting point to resolve tickets like #3560 & #3924
Thanks!