Use ractive from the parent module instead of directly depending on it.

[dantman]

Using 0.x doesn't solve the issues of version mismatch, as the parent may be depending on an older version, or eventually ractive may go 1.0.

Instead, by not including it in the dependencies we'll depend directly on whatever version of ractive the module using ractivate is using.

[dantman]

This should either be a 0.3 or 1.0.

[jonvuri]

Intuitively this seems wrong to me. devDependencies are things needed at build time (or other tasks appurtenant to build / test / deploy), and dependencies are things that your module needs at runtime - in this case, Ractive definitely qualifies. In fact, you then add a runtime check for Ractive to make up for the loss! (Note that this module itself is meant to be a build tool for the consumer, so it would be fine to have both it and Ractive as devDependencies on the other end.) I'm having a hard time seeing why this is better than passing "*" for the Ractive version, which would probably be fine for this module.

[dantman]

devDependencies is for anything you need build/test/etc time that isn't in dependencies.

dependencies is for anything you need at runtime and use entirely yourself.

But, this isn't a normal library where the library does everything with its dependencies, its a thin wrapper that returns an Ractive.parse result that is intended to be consumed by the exact same version of Ractive.

By directly depending on ractive an app that depends on ractivate ends up with a structure like:

node_modules/ractive/
node_modules/ractivate/
node_modules/ractivate/node_modules/ractive/

There are two independent copies of Ractive with different versions.

Say you require ractive "0.6.1", then a 0.6.2 with a backwards incompatible change is made you end up with:

• node_modules/ractive/ - 0.6.1
• node_modules/ractivate/node_modules/ractive/ - 0.6.2

The app will be broken by the new release until the app upgrades to 0.6.2, however if 0.6.2 includes a template change that's a mistake and needs to be undone/fixed (this has happened before) then the app would remain completely broken until 0.6.3 was released because of ractivate.

[dantman]

Basically ractive is more of a peer dependency for ractivate. However npm's peerDependencies is terribly broken and being considered for removal.

[jonvuri]

It's intended that you install ractive first - basically, to make it an unofficial peer dependency. Ractive won't be installed as a sub-dependency to ractivate if it's already available as a normal node module. If you do npm install ractivate:

ractivate@0.2.0 node_modules/ractivate
├── ractive@0.6.1
└── compilify@0.1.0 (through@2.3.6)

And then npm install ractive@0.5.1:

├─┬ ractivate@0.2.0
│ ├─┬ compilify@0.1.0
│ │ └── through@2.3.6
│ └── ractive@0.6.1
└── ractive@0.5.1

Obviously an issue. However, if you do it the other way around, npm install ractive@0.5.1 followed by npm install ractivate, ractive isn't included as a subdependency since it's already installed:

├─┬ ractivate@0.2.0
│ └─┬ compilify@0.1.0
│   └── through@2.3.6
└── ractive@0.5.1

This is also the way it happens when both ractive and ractivate are declared as dependencies and you do an npm install, which will probably be the case most of the time. Perhaps it could be made clearer that this is the intended way to use it in ractivate's README though.

Also, correct me if I'm wrong, but someone desiring a different version of ractive could still make the same mistake with this change. If ractive isn't already installed, it will be included as a subdependency with npm install since it's still a devDependency.

I think it's probably better to rely on npm's dependency system even if it's a little dicey. It's just simplest.

[dantman]

Also, correct me if I'm wrong, but someone desiring a different version of ractive could still make the same mistake with this change. If ractive isn't already installed, it will be included as a subdependency with npm install since it's still a devDependency.

devDependencies are not installed when one does npm install {package}.

[jonvuri]

Yeah, they are. Just tried it now (Node 0.10.33, npm 2.1.11) and the documentation agrees: https://docs.npmjs.com/cli/install (Heading 'npm install (in package directory, no arguments)', about 3 paragraphs down)

You have to pass the -production flag to only install normal dependencies.