Upgrade dependencies to remove npm install warnings

[raymondfeng]

Description

Upgrade dependencies to remove warnings from npm install.

Related issues

• Replace deprecated node-uuid with uuid module #1227

Checklist

• New tests added or existing tests modified to cover all changes
• Code conforms with the style
  guide

[bajtos]

@raymondfeng the changes themselves looks good, however I am concerned about possible breaking changes caused by upgrading async and qs 👇

[bajtos]

Do we know what were the breaking changes between async 1.x and 2.x? Can they cause a breaking change in juggler?

[mrfelton]

I remember 1 breaking change was related to loopback current context.

[bajtos]

The list of breaking changes can be found here: https://github.com/caolan/async/blob/d3f583a1d0e6d248b3dc5adbe20ac1c4ccdb92c5/CHANGELOG.md#breaking-changes

TL;DR: I think we are good to upgrade here.

Here are the selected items that I think may affect us:

1. Calling a callback more than once is considered an error, and an error will be thrown. This had an explicit breaking change in waterfall. If you were relying on this behavior, you should more accurately represent your control flow as an event emitter or stream.

2. Internal setImmediate calls have been refactored away. This may make existing flows vulnerable to stack overflows if you use many synchronous functions in series.

3. filter, reject, some, every, and related functions now expect an error as the first callback argument, rather than just a simple boolean. Pass null as the first argument

(1) and (3) can cause bugs where juggler is relying on the old async@1 behaviour. Hopefully, such problems would be caught by our unit tests, so we should be good here.

(2) is more subtle. juggler was originally written with async@0.x, which was not calling setImmediate. IIRC, async@1 added setImmediate calls, and this broke CLS/getCurrentContext. Now that async@2 is removing (some of) setImmediate calls, I think our code should not be affected, because it was written with the expectation that setImmediate is not called at all.

[bajtos]

Ditto, did you assess the impact of this change?

[bajtos]

AFAICT, qs is used only to parse dataSource/connector settings when a single URL string is provided.

qs's changelog can be found here: https://github.com/ljharb/qs/blob/8bd4c6cf12898f469838980317fec92007e5112a/CHANGELOG.md

Here is an overview of breaking changes:

• 6.0 is just dropping support for Node versions before 4
• 5.0 reverts back allowDots to false. This flag was introduced in 3.x defaulting to true (see ljharb/qs@33888bb).
• 4.0 reverts back handling of keys that overwrite built-in Object properties to the behaviour of 2.x versions, see make returning plain objects and allowing prototype overwriting properties optional ljharb/qs#98. IMO, typical connector settings shouldn't be using built-in property names, thus we shouldn't be affected by this change.

As I see it, the only thing that may break after this update is connection strings using key.subkey=value notation instead of key[subkey]=value. Considering that the dot notation is not documented in LoopBack docs, I think upgrade to qs@4+ shouldn't cause any significant breakage of existing apps.

[bajtos]

@raymondfeng I have looked up the release notes for you, see my comments above. I think this patch is safe to be landed to master (3.x). I think we shouldn't be upgrading 2.x LTS though.