add support for weapp

[taoqf]

#653 (comment)
I open this pr because of the gt reports.
@mcollina , stragely, I forked again and did the same change, I got failed message when I run npm run weapp-test first time. and I run npm test twice, it worked with no exception I got yesterday.
anyway, I hope this pr will be merged soon. thank you for your patience.

[codecov]

Codecov Report

Merging #660 into master will decrease coverage by 0.69%.
The diff coverage is 16.66%.

@@            Coverage Diff            @@
##           master     #660     +/-   ##
=========================================
- Coverage   93.22%   92.52%   -0.7%     
=========================================
  Files           8        8             
  Lines         664      669      +5     
  Branches      160      161      +1     
=========================================
  Hits          619      619             
- Misses         45       50      +5

Impacted Files	Coverage Δ
lib/connect/index.js	90.9% <16.66%> (-6.32%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5afa5ac...127ba09. Read the comment docs.

[mcollina]

This is ok now!

[imZack]

Why package-lock.json is in .gitignore?

This file is intended to be committed into source repositories, and serves various purposes:

Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.

Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.

To facilitate greater visibility of tree changes through readable source control diffs.

And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.

ref: https://github.com/npm/npm/blob/v5.0.0/doc/files/package-lock.json.md

[mcollina]

Because it's still a very experimmental technology and there have been a lot of bugs. Plus, it does not make the life of a maintainer easier. So, no, we should not use them.

[imZack]

Got it, I didn't notice about it too much before. Maybe we could also add a .npmrc file with package-lock = false

just like what eslint did eslint/eslint#8742

[mcollina]

@imZack definitely. Would you like to send a PR? I've it disabled globally, so it's not a big deal for me, but I can see why it's needed for others.

[boneskull]

generally I'd be in agreement, but I think we should reconsider this.

the last build of master passed, yet between then and now--without touching the code at all--something has broken to cause tests to fail.

one failure I found when running npm test in my working copy prompted PR #689. this PR also exhibits the second test failure, which I'm still trying to sort out.

the failing tests are adding significant friction to contributors, because we can't move forward until they're all fixed. package-lock could mitigate this, but it also could result in false positives if the test failures are due to production deps and not just dev deps.

maybe someone has written an npm bisect-type tool--I'd love to be able to go back in time and recreate the node_modules structure of the last passing build!

[mcollina]

@boneskull do you think we should remove support for weapp?

[boneskull]

@mcollina sorry, I should have been more clear, I'm writing in reference to #662.

[mcollina]

@boneskull you would like to revert package-lock? IMHO if it start to work as expected, I have no problem with it. I had more rm -rf node_modules in the last few months than in the rest of the years I have been doing node.