-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Remove underscore from meteor-base #9596
Remove underscore from meteor-base #9596
Conversation
@hwillson The |
Ouch, good catch @benjamn - I'll take a look. Thanks! |
340799a
to
b87a650
Compare
I've fixed the other error on the original PR - the |
First, thank you so much for taking the time to work on great improvements like this. AppVeyor won't build if there are any merge conflicts with the target branch as they build against a virtual GitHub branch which is meant to represent the "merge result", in an effort to try to provide early warning of what might eventually be a build a broken build. Currently, that merge conflict is just Lastly, thanks again for taking the time to work on great improvements like this. 😉🙏👏 |
@abernix Thanks for going out of your way to help contributors like me! |
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 an awesome change @jamesmillerburgess, thanks!
The code changes look great, so I don't have any feedback there.
I am concerned that this change will inevitably upset people who don't have underscore
explicitly added to their project. What do people think - are we okay with just documenting this in the History.md
and letting people figure things out when they get application errors because underscore
is now missing?
I'll mark this a request changes
even though the code is okay, just until we hash out a plan of attack for making this change as painless as possible for existing users.
I agree with you that it isn't nice to introduce breaking changes without some kind of deprecation warning, although I can't think of an elegant way to do that for this particular situation:
Besides being difficult to detect for a deprecation warning, that's a pretty odd set of criteria, so I'm not even sure there are non-trivial apps out there that meet them. Hopefully that means the blast radius will be quite small if we go forward with the change. |
I agree @jamesmillerburgess, I couldn't think of a better way of handling this either. I guess I'm just envisioning complaints rolling in from people who are used to just running That being said, I like progress, so my vote goes towards exactly what you've done - mention this in the Okay, enough rambling on my part - approved! 🙂 |
@@ -69,7 +69,7 @@ C.find().observeChanges({ | |||
Meteor.clearTimeout(nextStepTimeout); | |||
nextStepTimeout = null; | |||
} | |||
if (!fields.step && _.has(steps, fields.step)) { | |||
if (!fields.step && steps.hasOwnProperty(fields.step)) { |
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.
Generally we prefer Object.prototype.hasOwnProperty.call(steps, fields.step)
, but since this is a test and it passes, I think this is fine. The rationale is that hasOwnProperty
could be a field in the steps
object, which would mean steps.hasOwnProperty !== Object.prototype.hasOwnProperty
.
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.
Ah, I was wondering why I was seeing it used like that elsewhere. I will update my other PRs as well. Thanks!
packages/meteor-base/package.js
Outdated
@@ -1,6 +1,6 @@ | |||
Package.describe({ | |||
name: 'meteor-base', | |||
version: '1.3.0', | |||
version: '1.3.1', |
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.
Let's bump this to 1.4.0 so that the changes won't take effect until developers update to Meteor 1.6.2. This kind of change is appropriate for 1.6.2, I think, because 1.6.2 is all about various bundle size optimizations.
576501d
to
a91b407
Compare
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.
After talking about this in the issue triage meeting, we think decoupling underscore
from meteor-base
is a good idea, but we're afraid that lots of apps will be broken when they update, so it's important to add underscore
back, separately from meteor-base
. The way to do this is to write an "upgrader" that modifies the .meteor/packages
file by adding underscore
if meteor-base
is also used, assuming underscore
is not already there. This upgrader will run during meteor update
. See this file for lots of examples of other upgraders we've used over the years.
Thanks for pushing this forward!
Just to add to #9596 (review), if you don't have time to look into writing the upgrader, let me know and I'll dig into it. Thanks! |
I should be able to address the feedback for this and the other PRs either by tonight or tomorrow early morning. But I’ll let you know if I don’t have time and need some help. Thanks!
Best regards,
James
…________________________________
From: Hugh Willson <notifications@github.com>
Sent: Thursday, February 8, 2018 5:17:43 PM
To: meteor/meteor
Cc: James Burgess; Mention
Subject: Re: [meteor/meteor] Remove underscore from meteor-base (#9596)
Just to add to #9596 (review)<#9596 (review)>, if you don't have time to look into writing the upgrader, let me know and I'll dig into it. Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#9596 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/APOnDPQH0Re09UpKK2Y53jK4JARqUKLVks5tSx4ngaJpZM4RxjEt>.
|
4c8738f
to
da2477a
Compare
There are only a few uses of `underscore` in these apps, and two of them actually used `underscore` without having it explicitly listed in their `packages` file. This is a problem, because the apps were relying on the dependency from `meteor-base`, which we want to remove to cut down bundle sizes. For the `modules` test app, I've added `underscore` to the `packages` file, because it is using `_` in an assertion about the module system. For the other app and all other uses of `_`, rather than add `underscore` to the `packages` files, I took the modernization route and replaced the functions with their ES6 equivalents, and then removed `underscore` from all `packages` files.
This should shave down bundle sizes by 14.4 kb for many non-blaze projects. The other core meteor packages have not depended on `underscore` since meteor#9362. However, we are only able to remove this last dependency now due to the previous commit, which eliminated usages of `underscore` from apps that did not have the package listed in their `packages` files. This was causing CI test failures that now should be corrected. Any meteor apps currently using `_` without `underscore` listed in their `packages` file will need to add the package explicitly. Version number bumped from 1.3.0 to 1.3.1.
f0f8ca7
to
10620a4
Compare
I tested the upgrader with a simple app and it seemed to do what it was supposed to for each of the conditions. I also adjusted the entry in |
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.
Looking good! We'll get this into a beta soon!
This should shave down bundle sizes by 14.4 kb for many non-blaze projects.
The other core meteor packages have not depended on
underscore
since #9362. However, we are only able to remove this last dependency now due to the the first commit in this PR, which eliminates usages ofunderscore
from apps that did not have the package listed in theirpackages
files. This was causing CI test failures that now should be corrected.Any meteor apps currently using
_
withoutunderscore
listed in theirpackages
file will need to add the package explicitly.meteor-base
version number bumped from 1.3.0 to 1.3.1.Adjustments to test apps:
There are only a few uses of
underscore
in these apps, and two of them actually usedunderscore
without having it explicitly listed in theirpackages
file.This is a problem, because the apps were relying on the dependency from
meteor-base
, which we want to remove to cut down bundle sizes.For the
modules
test app, I've addedunderscore
to thepackages
file, because it is asserting thatrequire('meteor/underscore')._
equals_
. For the other app and all other uses of_
, rather than addunderscore
to thepackages
files, I took the modernization route and replaced the functions with their ES6 equivalents, and then removedunderscore
from allpackages
files.