Update deps

[zertosh]

• The update of defined and xtend are so we can get npm to dedupe them. It's already in Update deps & more insert-module-globals#42, Update deps & more deps-sort#4, Update deps module-deps#82 and Update deps browser-pack#56.
• I'm also updating and pinning punycode to 1.3.2 for deduping purposes. But I chose to not make it floating since url also has it pinned there.
• And I'm updating module-deps, despite that the ^ already covers the version, so that over in watchify I can count on Fix mysteriously disappearing "expose" and "entry" module-deps#80 always being in whatever is the next browserify version we publish.

The motivation for the deduping is #707 (comment).

---

@jmm and @terinjokes: This should be published as 9.0.9. But since #1222 hasn't been published, strict semver dictates that we move to 10.0.0. I think that's over kill for removing the "v" flag. I'll hold off publishing until you chime in.

[terinjokes]

LGTM 👍 @jmm?

[jmm]

This all sounds good. Having to pin a dep like punycode because it's pinned in another dep seems a little wonky though. Then it'll get out of sync if url updates it and no one thinks to update it here. npm doesn't provide a more elegant way to accomodate that situation, eh?

Re: the new version number, I have a bit of mixed feelings about that, since it probably wouldn't break 99.9% of things, but ultimately I guess I'd err on the side of caution / predictability and bump the major unless this stuff can wait until some other things that would necessitate that anyway get rolled in. I think there's some urgency for you to get this to fix stuff in watchify though, right @zertosh? At least it would be a super easy changelog to digest.

BTW, FWIW I'm still operating on the guidelines I was pointed to here that "Declaring formal releases remains the prerogative of the project maintainer." -- therefore not for me to say :)

@terinjokes were you in favor of just staying at v9?

[terinjokes]

@jmm With the process changes, I'll be in favor of a v10 (since it seems like it could break things subtly.

And true, I believe I've only published patch releases before.

---

EDIT

npm doesn't provide a more elegant way to accomodate that situation, eh?

The multi-stage install that npm@3 brings should dedupe a bit more than the current install. I'll have to do some tests to see if it would figure this one out.

[jmm]

@terinjokes Yeah, sorry, I just got to that one (reading the whole thing in a bit) and saw that it might be a moot point.

And true, I believe I've only published patch releases before.

I figured that, at least as far as it pertains to me at this point in time, that meant any release, even patch level. What would you say that means by "formal release" -- major only? major.minor? everything?

[zertosh]

. I think there's some urgency for you to get this to fix stuff in watchify though

@jmm Not urgent, just a convenience. But since the process update is kind of important, I figured this should ride along.

"Declaring formal releases remains the prerogative of the project maintainer."

O_O eep. I don't know. Is formal = major? Or does this mean that publishing rights to npm may or may not be given a contributor?

The multi-stage install that npm@3 brings should dedupe a bit more than the current install. I'll have to do some tests to see if it would figure this one out.

@terinjokes When that time comes we should totally revisit this. We should be mindful of changes to url nonetheless.

[terinjokes]

Unless we have clarification, probably best to allow substack to tag the releases then.

[zertosh]

Makes sense to wait then - don't want to overstep bounds w/o clarification.

[jmm]

I don't mean to screw up anyone else's workflow -- I assumed that people who've been collaborators here longer than me might have different parameters for how to contribute. (I think I was the most recent addition until you, @zertosh.)

Or maybe you're on to something here:

Or does this mean that publishing rights to npm may or may not be given a contributor?

Maybe being designated an npm maintainer is implied thumbs up for cutting releases?

@terinjokes

The multi-stage install that npm@3 brings should dedupe a bit more than the current install. I'll have to do some tests to see if it would figure this one out.

@zertosh

@terinjokes When that time comes we should totally revisit this. We should be mindful of changes to url nonetheless.

I was thinking about that too, but I was wondering if it'll also dedupe on npm update. I just asked over here (which only mentions npm install): npm/npm#6912 (comment). If that's the case, and once it arrives, then I think it'd make sense to depend on ~1.3.2 here (or whatever is the relevant version at the time) and let url dictate the exact version via npm. Or maybe even now, unless someone is really going to be keeping an eye on url. Is it even likely to cause a problem if they depend on different minor / patch versions?

[terinjokes]

Having thought about this over the day, I'm not sure I like pinning to punycode here, since it creates a maintainability issue for us to remember to upgrade it when we upgrade url. @zertosh this is to save a few megabytes on install, correct?

[zertosh]

this is to save a few megabytes on install, correct?

@terinjokes correct. Also, it's not like url is getting it's punycode - when you require('url'); it actually gets the punycode that's specified in builtins. So, the version specified by url itself doesn't matter for browserifying purposes.

EDIT: #funfact

[zertosh]

Maybe being designated an npm maintainer is implied thumbs up for cutting releases?

@terinjokes I'm starting to think that. hughsk's policy over at envify is "In the future I'd say submit a PR, and if you don't hear from me after a day then merge away :)" hughsk/envify#23 (comment). And he gave me the same collaborator agreement.

[terinjokes]

@zertosh I've felt comfortable merging in about the same time period. It's cutting releases that I'm not sure of.

[ghost]

All of this looks great, you don't need my permission to cut a release! Just remember to add a quick description to the changelog.

[terinjokes]

With that out of the way, to the issue at hand.

I continue to prefer not pinning punycode, even if it does mean two get installed until user switches over to npm@3. As an aside, I'm not even sure why punycode is listed as a dependency since recent node versions will never resolve to it (but that's an issue for that repo).

Ignoring the questionable change to process.nextTick, do we have any other PRs pending (or about to be pending) that would require the bump?

[zertosh]

@terinjokes I think that's it for now. I went ahead and made punycode ^1.3.2. I'll merge this in and #1231. You can do the honors of cutting 10.0 😄

[terinjokes]

@zertosh ok, happening now.