search

kevinbeaty / any-promise

NOTE: You probably want native promises now
MIT License
179 stars 17 forks source link

Recommended dependency definition for libraries? #26

Closed analog-nico closed 8 years ago

analog-nico commented 8 years ago

I am getting ready to publish request-promise-any and I wonder what the best way to define the any-promise dependency in the package.json.

  1. dependencies or peerDependencies?
  2. Loose version ^1.0.0 or latest version ^1.3.0?

dependencies and ^1.3.0 increase the chance that a project installs different versions of any-promise considering that many libraries depend on any-promise. Since you fixed #8 this might not be too bad. But still you might see reasons to go for peerDependencies and ^1.0.0 to reduce the chance of multiple versions installed.

mz uses dependencies and ^1.0.0. Is that what you would recommend?

kevinbeaty commented 8 years ago

I don't have a strong opinion. If it were me, I'd probably just add a dependency to ^1.3.0, but ^1.0.0 would not break anything. The only enhancement since 1.0.0 that may affect library usage was #8 as you mentioned which was introduced in ^1.1.0. The other enhancements affected registration only.

I've never used peer dependencies so don't have any input there.

analog-nico commented 8 years ago

Thanks @kevinbeaty ! Since you don't see any other cross-compatibility issues I decide to use ^1.0.0. The reason is that the project which uses my library may have any-promise@1.0.0 installed. This situation might not be too rare if the project applied npm shrinkwrap before 2016-02-03. Thus if my library depended on any-promise@^1.3.0 npm would install a second version of any-promise in the node_modules folder of my lib. However, @1.0.0 would be in charge of registering the preferred Promise implementation. Since @1.0.0 does not register the Promise implementation globally yet, my lib would use the other version which didn't receive a registration command and falls back to the native Promise.

Secondly, I decide to use regular dependencies rather than peerDependencies. In case of request-promise-any primarily because peerDependencies could trip up some users in case they forget to install any-promise. In general, however, any-promise may be used in a library but the project that uses the library doesn't care about using a specific Promise implementation. In this case any-promise is automatically installed, falls back to the native Promise implementation, and the user doesn't have to do anything. Less things that can go wrong == less support and documentation needed. ;)

mz made wise choices! :)