Add support for installation via Bower

Just had a question about trying to load snowplow through Bower, in which case the sp.js file would be bundled with the application as an installed dependency.

To implement this, I did the following

1. Removed .gitignore from the dist folder in my fork of snowplow-tracker-javascript
2. Ran grunt
3. Committed the generated files
4. Added this fork as a dependency in bower.json of my application

Essentially, in this case, the build would handle injecting sp.js into a script tag (before any application scripts) in index.html.

This would mean not having to include that part of the setup snippet that creates the script tag and sets the src, essentially now I would only need / want

 (function (p, l, o, w, i) {
      if (!p[i]) {
        p.GlobalSnowplowNamespace = p.GlobalSnowplowNamespace || [];
        p.GlobalSnowplowNamespace.push(i);

        p[i] = function () {
          (p[i].q = p[i].q || []).push(arguments);
        };

        p[i].q = p[i].q || [];
      }
    }(window, document, null, null, 'snowplow'));

When trying this, I no longer see snowplow analytic traffic in Chrome network tab.

Is this possible? Eventually, I would like my build to handle uploading files to S3 / Cloudfront, either as individual files or conact / min file, and this would reduce the coupling between this init script (since it requires specifying a path), and how snowplow gets loaded into my application. We also want to be able to version our fork as we will be modifying it as need to support additional tracking metrics over time, which again help with not having to specify a path in the setup snippet.

Any thoughts / feedback appreciated.

[rarkins]

@alexanderdean wrote:

Loading analytics libraries in an async fashion from CDNs (as we do today) is pretty much the gold standard these days

Assuming by “gold standard” we mean the ideal against which others are compared, this is definitely not the case anymore.

Much preferred is to pull third party dependencies via npm as part of a website’s frontend build, which gives benefits such as:

• Third party services can notify you/submit pull requests whenever your dependencies are updated to npm, or incorporate this as part of the build
• You can use build tools like webpack or browserify to control how/when you load analytics as part of your JS flow
• Gives you ability to serve dependencies off the same domain as your application JS (useful for HTTP2, for example)

Unfortunately, most “SaaS” services including analytics do like you describe - load third party files from CDNs and give no other choice. This also gives them the chance to “move fast and break things” without customers noticing, because if they publish a faulty update they can quickly replace it thanks to rather low expires times on their CDN resources. You notice this if you run something like PageSpeed or WebPagetest and they point out the absurdly low expires of many of these CDN-hosted files.

I prefer the approach used by Mixpanel, who support both the async-loaded CDN scripts as well as “roll your own”.

Their javascript tracker npm repository: https://www.npmjs.com/package/mixpanel-browser

Example JS you can build/bundle with client:

var mixpanel = require('mixpanel-browser');
 
mixpanel.init("YOUR_TOKEN");
mixpanel.track("An event");

[alexanderdean]

Thanks @thescientist13 - that makes sense. We’ll reboot this ticket then when this release gets scheduled. Cheers for checking in!