## Reviewing Dependencies ### NPM, Ember, and SemVer Created by [Xander Dumaine](https://www.xdumaine.com) / [@xdumaine](https://github.com/xdumaine) released under [cc by-nc 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/)
## Disclaimer I'm not an expert, I'm just someone who has been frustrated one too many times
## SemVer - Embrace new versions. You aren't going to run out of integers. - Do not be afraid of 1.0.0 - if something depends on you, 0.x.y is not acceptable. - If you don't follow the spec, you are not using SemVer
## SemVer - New functionality is *ALWAYS* (at least) minor version - Breaking changes are *ALWAYS* a major version - Patches are *ONLY* for bug fixes
## SemVer - You *CAN* major version bump for new features - You *CAN* major version bump for "risk" of break (i.e., refactor)
## SemVer A bug fix that changes behavior is still a breaking change. This is not a patch change, it requires a major version bump.
## SemVer You can patch older major and minor versions. It's just more work.
## SemVer Matching The rules are basically out the window pre 1.0.0. If something depends on your project, it should be 1.0.0. If it's not "ready" for 1.0.0, then why does another project depend on it?
## SemVer Matching - caret `^` means "match any minor versions" - `^1.1.5` == `1.x.y` such that x >= 1 and y >= 5 - will match `1.1.10` and `1.2.0` but not `2.0.0` - Preferred for any modules you trust
## SemVer Matching - tilde `~` means "match any patches" - `~1.1.5` == `1.1.x` such that x >= 5 - will match `1.1.10` but not `1.2.0` and not `2.0.0` - Preferred for modules with history of being "bad" (breaking changes without major version bump)
## SemVer Matching - No symbol means "pinned" - `1.1.5` will not match `1.1.6` - generally a bad idea, but useful of accidental breaking changes
### NPM and Package.json
### NPM and Package.json - Dependencies: things your app/addon/module uses to run - DevDependencies: things your project uses to build/serve/etc
### NPM and Package.json If it runs in the browser, dependencies. If it runs on the dev or build machine, devDependencies.
### NPM and Package.json - PeerDependencies: like dependencies, but used when you expect - that your consuming application will depend on it as well e.g. ember-purecloud-components depends on ember-purecloud-style but web-directory depends on both, so ember-purecloud-components should list ember-purecloud-style as a peerDependency
### Broccoli and funnels RTFM: https://github.com/broccolijs/broccoli-funnel TL;DR: find some files relative to a path and make them appear to be elsewhere so they can be imported/exported/consumed
### Broccoli and funnels ```javascript // index.js // Funnel the fonts dir of a dependency into my styles dir const path = parent.nodeModulesPath + '/ember-purecloud-style'; let stylesTree = new Funnel(path, { srcDir: 'app/styles/fonts', destDir: 'styles/ember-purecloud-style' }); ``` ```less /* addon/styles/my-component/style.less */ @import 'ember-purecloud-style/icomoon'; ``` See ember-webrtc-components index.js
### Broccoli and funnels Funneling items from dependencies often shows you where your dependencies are wrong. (i.e., devDependencies vs dependencies vs peerDependencies)

Thank You.

        				// any questions?