Removing blueprint and moving dependencies to npm

[gmurphey]

With ember-cli moving away from bower dependencies, thought it would be beneficial to move ember-hifi's dependencies over to npm.

[noslouch]

This looks great, but I'd like for it to run on circle before we merge. I just updated our settings so that forks can run in our build system; would you mind adding a new commit and pushing again in order to kick off a build?

I think an update to the readme to take out the generator command should do the trick ;)

[gmurphey]

I just realized that app.import can't use node_modules paths. I'll update this to build a vendor tree.

[gmurphey]

I'm not sure what the node-sass errors are about, but I see them on a clean master run of yarn test as well. Will try to dig into this later.

[gmurphey]

So I think I've narrowed these failures down to an issue with yarn removing node-sass artifacts after some of the ember-try scenarios (yarnpkg/yarn#3506). I was able to reproduce locally, and it seems, from my limited testing, that this is fixed in yarn 0.27 (pre-release, atm). I'm not sure if it's possible to have circleci use a specific version of yarn. If not, I'd be happy to submit a PR that has circleci use npm (which doesn't face this issue) until circleci is updated.

[noslouch]

Oh boy. Thanks for tracking this down. For every problem yarn solves, it seems to introduce some new ones. Such is the way with technology tho. I'll see if I can update which yarn circle uses.

[noslouch]

should these go into devDependencies?

[gmurphey]

The consuming apps will need these to build the addon's vendor tree. If they're in devDependencies, they won't be available to the app at build-time.

[noslouch]

I added a command to our circle config that uses that yarn pre release and everything's looking green!

One thing: I'm not 💯 on how dependencies vs devDependencies affects upstream apps, so I'm curious if those broccoli deps would affect app builds.

let me know your thoughts on that question and I'll merge 'n' release.