Bump stringstream from 0.0.5 to 0.0.6

[dependabot]

Bumps stringstream from 0.0.5 to 0.0.6.

Commits

• fee31c5 0.0.6
• 2f4a9d4 Merge pull request #9 from mhart/fix-buffer-constructor-vuln
• afbc744 Ensure data is not a number in Buffer constructor
• See full diff 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.

---

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 squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @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

[coveralls]

Pull Request Test Coverage Report for Build 566

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 94 unchanged lines in 11 files lost coverage.
• Overall coverage decreased (-5.04%) to 84.007%

---

Files with Coverage Reduction	New Missed Lines	%
src/messaging.ts	1	87.5%
src/JestProcessManagement/JestProcess.ts	1	98.11%
src/decorations.ts	1	91.67%
src/DebugConfigurationProvider.ts	1	86.67%
src/Coverage/CoverageOverlay.ts	2	91.18%
src/TestResults/TestResultProvider.ts	2	95.52%
src/helpers.ts	4	89.61%
src/diagnostics.ts	5	85.71%
src/Coverage/CoverageCodeLensProvider.ts	6	15.79%
src/extension.ts	8	69.44%

Totals
Change from base Build 557:	-5.04%
Covered Lines:	690
Relevant Lines:	806

---

💛 - Coveralls

[stephtr]

@connectdotz I assume we can easily merge this?

[connectdotz]

I would think so. There are other security alerts as well, what do you think we do the following:

1. generate PR for all the other security alerts
2. rebase these PRs to beta then merge
3. build a new pre-release 3.0.1 to include these fixes
4. both you and I download and run 3.0.1 to ensure nothing breaks

if all goes well, maybe we should consider release 3.0.1 to master and vscode marketplace next week?

[connectdotz]

looks like 2 security alerts couldn't auto generate PRs... when I rebase the generated PRs, there are a few merge conflicts since beta yarn.lock is quite different from master... I now think it is probably better if we merge beta to master first, then regenerate the security PRs from the new master to avoid manually resolving conflicts... what do you think?

[stephtr]

The two alerts hadn't been fixed, since for example for fixing querystringify one would also have to update its dependent url-parse.
Those merge conflicts can be resolved by writing "@dependabot rebase". But yes, it depends on how we generally handle yarn.lock conflicts across branches. We could either set dependabot to always directly target the beta branch or in principle we could also merge those dependency bumps to the master branch and keep the master's lock file when merging changes from beta (and update the lock file afterwards).

[connectdotz]

rebase is easy but resolving merge conflicts of yarn.lock manually is quite tedious, especially most dependencies are indirect. I would avoid that as much as possible. I think the easiest way would be first merging beta to master, then trigger security PR (quite easy) against the new master, at least 7 of the 9 can be merged this way without conflict.

The other 2 I haven't looked deeply into, it will be great if you can follow up with those...

btw, did you get a chance to run 3.0.0 on windows, I think this might be the biggest question mark blocking beta merge to master, we don't have any confirmation from windows users... if you can run 3.0.0 on windows then I could merge beta to master and at lease incorporate 7 security alerts this weekend...

[stephtr]

rebase is easy but resolving merge conflicts of yarn.lock manually is quite tedious, especially most dependencies are indirect. I would avoid that as much as possible. I think the easiest way would be first merging beta to master, then trigger security PR (quite easy) against the new master, at least 7 of the 9 can be merged this way without conflict.

I think it would be enough to just keep one version of the lock file and manually run yarn, which automatically adds all packages which hadn't been already in the lock file.
But why not updating the dependencies in beta, since there aren't any commits which aren't included in beta yet?

The other 2 I haven't looked deeply into, it will be great if you can follow up with those...

I'll do it as soon as we have decided or merged beta->master.

btw, did you get a chance to run 3.0.0 on windows, I think this might be the biggest question mark blocking beta merge to master, we don't have any confirmation from windows users... if you can run 3.0.0 on windows then I could merge beta to master and at lease incorporate 7 security alerts this weekend...

I have run a few test repos and so far all of them ran smoothly.

[connectdotz]

But why not updating the dependencies in beta, since there aren't any commits which aren't included in beta yet?

beta has introduced quite a few updated packages so the yarn.lock looked very different from master, you can see what kind of merge conflicts after rebasing the auto-generated PR, which is based on master, to beta here

[stephtr]

That's what the "@dependabot rebase" command is for. I'll rebase all to beta then.

Ups, ok that isn't working. I'm going to update the components by hand.

[stephtr]

@dependabot rebase

[stephtr]

Closing in favor of #472. The beta branch should have all security issues patched now.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.