Remove dependencies for events logging

[scottsfarley93]

In response to #188, this PR investigates the increase in bundle size introduced in #183 and attempts to reduce the increase by changing the dependencies used in logging interaction events.

[andrewharvey]

For comparison

v3.1.1: 37K
v3.1.2: 1.1M
this PR:131K

Not sure what the split of https vs sha.js is but for reference it looks like mapbox-sdk-js and mapbox-gl-js both use XMLHttpRequest without any overhead.

https://github.com/mapbox/mapbox-sdk-js/blob/master/lib/browser/browser-layer.js
https://github.com/mapbox/mapbox-gl-js/blob/master/src/util/ajax.js

Wondering if it's worth doing the same here.

[scottsfarley93]

Using XMLHttpRequest, the min.js file size is now 75132 bytes.

[andrewharvey]

Would === bet safer? It's what's used at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/indexOf#Checking_occurrences

[andrewharvey]

@scottsfarley93 Thanks for fixing these things up.

I wanted to make some comments about the project/development in general. It's not for me to dictate how things are done, but I've been finding it hard to keep tabs on development and maintenance of this project. I'd prefer if we could:

1.Try to keep each PR contained to one issue, it's easier to review and keep track of where changes are being made.

2. Follow (or update) the deploy instructions https://github.com/mapbox/mapbox-gl-geocoder/blob/master/CONTRIBUTING.md#deploying and have a commit for each release (instead of bundling releases as part of other code changes). At the moment it's hard to see where releases are happening because they are mixed in with other commits.

3. Make a PR for each release, this gives an opportunity for a review of the release before it's pushed out, to hopefully catch any potential issues beforehand.

4. If significant changes and new features are being released, use a minor version bump instead of a patch release, following semver (for example, in my opinion the events logging was too large a change for a patch release).

[andrewharvey]

This looks good to me, thanks for improving this. I haven't done any testing though.

[scottsfarley93]

@andrewharvey thanks for the review and the contribution feedback. Quick question there -- I'm not sure I follow the order of operations on the deployment instructions.

Based on your suggestion, I think the following order makes the most sense, but wanted to double check:

1. Make feature changes/bug fixes in PR
2. Merge PR to master
3. Update changelog and version in new PR
4. Merge changelog/version PR into master
5. Tag release and npm publish

Let me know what you're thinking there. I can update the docs accordingly once we've nailed down the steps.

[andrewharvey]

@scottsfarley93 That's right, I find that approach, forcing releases to have their own commits rather than doing a release together with other commits, a lot clearer and better practice and what has historically been happening. #198 clarifies that.