sanctuary-def dependency

Sanctuary depends on sanctuary-def, as specified in package.json. Furthermore, Sanctuary is only compatible with certain versions of sanctuary-def. @codedmart recently brought it to my attention on Gitter that the example for create does not work if one uses the current version of Sanctuary (v0.11.1) with the current version of sanctuary-def (v0.9.0).

There are (at least) two things we should consider:

• specifying this constraint in package.json, if possible; and
• versioning the two packages such that sanctuary@X.Y.Z always depends on and works with sanctuary-def@X.Y.Z.

[Avaq]

Here’s what I think we should do:

1. Separate all of sanctuary into small modules, each with a peer dependency on sanctuary-def (and possibly sanctuary-type-identifiers and other shared dependencies):
   • sanctuary-either to contain the Either type, its Repr, and associated functions
   • sanctuary-maybe to contain the Maybe type, its Repr, and associated functions
   • sanctuary-list for list related functions
   • sanctuary-string for string related functions
   • sanctuary-strmap for the StrMap type, its Repr, and related functions
   • …more
2. Create a sanctuary-prelude library which takes from each of the above libs to provide a set of common tools.
3. The sanctuary library will have a single function. To load sanctuary-prelude and the shared peer dependencies like sanctuary-def, and instantiate the prelude with a default def.

People who want an out-of-the-box experience will use sanctuary, people who want a customized one will use sanctuary-prelude, people who want only parts of the functionality will assemble their own utility belt from the available underlying libs.

This tackles several problems:

1. “The library is monolithic”: Now we can choose what we want to include. Maybe in the future, each lib can even slit up into stuff like sanctuary-maybe-type, sanctuary-maybe-from-nullable. This package structure is “composable” all the way down to sanctuary.
2. (And this is personal:) “My colleagues are using require('sanctuary') directly, which defeats the point of disabling type-checking”: Now, I will depend only on sanctuary-prelude, and provide my own assembly which they have to use.
3. “My sanctuary-def is not compatible with yours”: Since all packages but sanctuary have it as a peer dependency, they will all use the same version and NPM will show it when one is not compatible and should be down or upgraded.
4. “I want to use my ENV_X to determine whether to check types”: The community is now free to provide many Sanctuary assemblies, since it’s very easy to set up. Just depend on the compatible sanctuary-* packages and export create(myDef).

[rickmed]

I really don’t know the internals of sanctuary so I have no idea what is possible but I assume that each of those packages would need sanctuary-def (78 kb) and sanctuary-type-classes (45kb). Right now sanctuary is 100kb, let’s say sanctuary-maybe would me 15kb. Would it make sense to have a separate package of 15kb with 123kb of dependencies? In that case, me as a user, I would prefer to download an es6 modularized sanctuary and tree shake it myself. Other option is to ask if you are downloading a single package probably you are working on a small project and you would not need type checking, so remove type checking on individual packages -if possible.