Bump grunt-contrib-watch from 0.6.1 to 1.1.0

[dependabot-preview]

Bumps grunt-contrib-watch from 0.6.1 to 1.1.0.

Changelog

Sourced from grunt-contrib-watch's changelog.

v1.1.0:
date: 2018-05-12
changes:
- Update to tiny-lr@1.1.1, lodash@4.17.10, async@2.6.0
v1.0.1:
date: 2018-04-20
changes:
- Update to gaze@1.1, lodash@4
v1.0.0:
date: 2016-03-12
changes:
- Updated tiny-lr, gaze, async and lodash dependencies.
- Fix endless loop issue with atBegin/nospawn.
- Expose hostname parameter of tiny-lr.
- Support cwd.event to emit events relative to path.
- Removed peerDependencies setting.

Commits

• 3b7ddf4 v1.1.0
• 72b1214 Updating dependencies, async, lodash and tiny-lr
• 5adb27c Merge pull request #543 from digitalbazaar/master
• 6ec71e9 v1.0.1
• 7d20933 Update copyright year
• e3d19df Update ci configs
• d117574 Updating ci configs
• 99410a7 README.md: Fixed typos (#536)
• f07311b Update tiny-lr dependency to 1.x
• 7f8cf80 Add local grunt-cli
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Note: This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

You can always request more updates by clicking Bump now in your Dependabot dashboard.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge
• @dependabot reopen will reopen this PR if it is closed
• @dependabot ignore this [patch|minor|major] version will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Pull request limits (per update run and/or open at any time)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

[jywarren]

Tested locally!

[jywarren]

Hi @greysteil please don't read this on New Year's Day but once you're back online, i was wondering if the extra merge commit here invalidates this PR from contributing to the compatibility score? The auto-rebase is really nice, but the rate that node module updates come in is so fast, we've seen it as a bottleneck in merging updates in a node environment. Each merge has to trigger like 8 other PRs to be rebased. So I tried just merging using the GitHub interface here to save time.

Any tips on the super-fast-moving node environment? We've had trouble keeping up. Also, noting #196 where many node module updates don't affect our src tests, but do affect our build/compile process, which isn't itself tested. We're planning to add tests to confirm that our build process is tested, but it's starting to seem a bit meta... any thoughts on that issue?

[greysteil]

Hey, sorry for the slow reply on this one - I did read it on New Year's Day, but didn't reply as I needed the break! 🙂

Good question. A couple of things:

• Adding a merge commit will stop @dependabot rebase from working, but you can use @dependabot recreate instead, so it shouldn't cause too many issues
• I think we can improve the way Dependabot does rebases when there are multiple PRs open. Specifically, I'm thinking about adding an option where it only rebases one-by-one, so there's less CI load at any one time, and if you have automerge enabled, or are merging the PRs manually as you go, in total there are fewer CI runs.

What do you reckon?

[jywarren]

Oh thank you! What about (a)dependabot rebase-and-merge, so that if all tests pass upon rebase, the merge is automatic once the rebase and tests complete?

…

On Wed, Jan 9, 2019, 12:03 PM Grey Baker ***@***.*** wrote: Hey, sorry for the slow reply on this one - I did read it on New Year's Day, but didn't reply as I needed the break! 🙂 Good question. A couple of things: - Adding a merge commit will stop @dependabot rebase from working, but you can use @dependabot recreate instead, so it shouldn't cause too many issues - I think we can improve the way Dependabot does rebases when there are multiple PRs open. Specifically, I'm thinking about adding an option where it only rebases one-by-one, so there's less CI load at any one time, and if you have automerge enabled, or are merging the PRs manually as you go, in total there are fewer CI runs. What do you reckon? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#174 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJw0qJZrd8vg05VQy2MkwJhCzGrC2ks5vBiC8gaJpZM4ZH38z> .

[jywarren]

We have started putting "grunt build" into our Travis pre_script by the way, so that the build task gets tested too; this gives us more confidence that the new dependencies don't break the compiling step. With this our dependabot merges have been much faster - I think it may be a good idea to suggest this to people. About half the dependencies we are merging are to the build pipeline and not actually tested module code (browserify, grunt packages like grunt-contrib-concat).

…

On Wed, Jan 9, 2019, 11:16 PM Jeffrey Warren ***@***.*** wrote: Oh thank you! What about (a)dependabot rebase-and-merge, so that if all tests pass upon rebase, the merge is automatic once the rebase and tests complete? On Wed, Jan 9, 2019, 12:03 PM Grey Baker ***@***.*** wrote: > Hey, sorry for the slow reply on this one - I did read it on New Year's > Day, but didn't reply as I needed the break! 🙂 > > Good question. A couple of things: > > - Adding a merge commit will stop @dependabot rebase from working, > but you can use @dependabot recreate instead, so it shouldn't cause > too many issues > - I think we can improve the way Dependabot does rebases when there > are multiple PRs open. Specifically, I'm thinking about adding an option > where it only rebases one-by-one, so there's less CI load at any one time, > and if you have automerge enabled, or are merging the PRs manually as you > go, in total there are fewer CI runs. > > What do you reckon? > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#174 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AABfJw0qJZrd8vg05VQy2MkwJhCzGrC2ks5vBiC8gaJpZM4ZH38z> > . >

[greysteil]

I think that's a good suggestion. I'm a little underwater right now, but will try to get a rebase and merge option added when things calm down! 🙂