## 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
- 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?