Separate modules

[jussi-kalliokoski]

Fixes #47.

[tomek-he-him]

One thing to consider would be versioning. The options I see are:

1. version each module independently; major/minor/patch-bump trine upon any major/minor/patch change in any of the modules
2. version everything together; major/minor/patch-bump trine and all other modules upon any major/minor/patch change in any of the modules

I guess option 1 would be ideal, but is it realistic?

[tomek-he-him]

Another thing I’ve been thinking about recently: npm installs a package named a/b/c to ./node_modules/a/b/c. Would it make sense to publish trine as 'trine' and trine/boolean/and as 'trine/boolean/and'?

There’s one advantage. Someone switching to depend on 'trine/boolean/and' instead of on 'trine' wouldn’t have to make any changes to his source code.

So you could easily switch from prototype to production:

$ npm install --save trine
# Work your wonders, helping yourself from any `trine/…` function.
# After some time the thing is ready.
$ npm rm --save trine; npm install --save trine/boolean/and trine/number/add
$ npm publish

I don’t know how npm would react to things like npm install trine trine/boolean/and though – we’d have to test it first.

[jussi-kalliokoski]

I guess option 1 would be ideal, but is it realistic?

Ideally (considering a balance between maintainability and avoiding duping) I think we should do the same as lodash, i.e. everything is released together, but cross-dependencies are semver-tagged to latest major release (e.g. `"lodash.pick": "^3.0.0"). However, I'm not sure what to do while we're still at 0.x.x release. But #19 aside, things are starting to stabilize and be relatively consistent, and because most modules really only do one thing and have no overloads, over time most modules will most likely even freeze (refactoring / perf improvements / documentation / bugfix changes aside), so I think most changes will be adding new features. That means we could probably soon bump to 1.0.0, and will likely stay there for a long time (at least until the bind operator proposal is dropped and we have to come up with a new API, heh) and adopt the lodash approach.

I don’t know how npm would react to things like npm install trine trine/boolean/and though – we’d have to test it first.

Interesting idea. Unfortunately npm requires namespaces to start with @ and they can only be one level deep (e.g. @trine/boolean.and). It would've been to magical to be true anyway 😆, consider this:

npm install trine
node -e 'require("trine/boolean/and")' # loads `node_modules/trine/boolean/and.js`
npm install trine/boolean/and # we're installing this inside the trine package, `node_modules/trine/boolean/and/`
node -e 'require("trine/boolean/and")' # loads `node_modules/trine/boolean/and.js` because `.js` is prioritized over `/index{ext}`

[tomek-he-him]

Unfortunately npm requires namespaces to start with @ and they can only be one level deep

True. I thought I had read it somewhere on https://github.com/npm/npm/issues, that npm really doesn’t care what characters there are in a name – and @…/… is only a convention which makes npm create a new folder.

But that must have been a false memory :) In fact npm install trine/boolean installs from https://github.com/trine/boolean :)

I think we should do the same as lodash, i.e. everything is released together, but cross-dependencies are semver-tagged to latest major release (e.g. `"lodash.pick": "^3.0.0").

I’m no heavy user of lodash – and their repo doesn’t tell me much – but what they do seems to be somewhere between my two propositions. Do I get it right?

That means we could probably soon bump to 1.0.0, and will likely stay there for a long time

I hope so :) But in case a breaking change in trine/boolean/and is inevitable, I don’t really see much reason to bump trine/number/add as well.

And I don’t see anything wrong with this too:

{
  "name": "trine",
  "version": "12.4.1",
  "dependencies": {
    "trine.boolean.and": "^2.3.2",
    "trine.number.add": "^1.2.5",
    …
  },
  …
}

[jussi-kalliokoski]

I’m no heavy user of lodash – and their repo doesn’t tell me much – but what they do seems to be somewhere between my two propositions. Do I get it right?

Yes, i.e. for every new release, everything gets bumped regardless of whether it's changed, yet the dependency tags stay the same. However, lodash doesn't have any external dependencies, whereas Trine does (babel-runtime), which is why sim-release makes even more sense because even though the code in Trine might not have changed, we will want all methods to use the same version of babel-runtime, and that is hard without bumping everything every time.

[tomek-he-him]

Yeah, good point.