RFC; Promote coffee-script as peerDependency in scripts

[mal]

At present quite a lot of hubot-* plugins list one coffee-script version or another as a dependency. Of those, many are specifing the same version that hubot itself depends on, and thus it should only been needed for testing and should probably be in devDependencies.

Some scripts however require more recent versions of coffee-script for various reasons, by listing it in peerDependencies rather than dependencies we get the benefit of npm detecting conflicting scripts at install time rather than waiting for everything to explode when bin/hubot gets executed.

Given that coffee-script isn't in the script template's _package.json at all (and doesn't need to be) I'm not sure what the best approch here would be (assuming this all makes sense).

One possibility is porting #27 over to allow optionally specifing the coffee-script version at app creation time, at which point we have the generator write it into peerDependencies as part of the generation. The only problem I forsee with this is that it might not be apparent at creation time that a newer version than 1.6.3 might be required. To combat this a sane default for new scripts might be ^1.6.3.

This could potentially lead to some weirdness where a peerDependencies conflict should have arisen but a package erroneously lists the version constraint as ^1.6.3 while in reality requiring a more recent minimum version. My hope is that with some clear documentation it should be a relatively trivial fix (update package.json so next time it will conflict and warn the end user about incompatible scripts at install time).

Hope all that makes some semblance of sense, look forward to hearing your thoughts!

[technicalpickles]

I think this is line with my thinking, thanks for putting it together!

I had some concerns about peerDependencies is I've seen references to it going away, but I was just reading npm/npm#6565 that it's less being deprecated, as the behavior being changed.

[mal]

Have continued mulling this over and gone over the various threads on the topic again (#27, #6, hubotio/hubot#863, hubotio/hubot#770 and #11). I see two options based on the various suggestions and ideas put forward:

---

NOTE: I picked ^1.7.0 so as to simply things (the bootstrapping change was in 1.7.0), making life easier when it comes to running tests.

A

1. hubot removes from explicit dependency on coffee-script@1.6.3
2. hubot adds coffee-script@^1.7.0 to devDependencies (for testing)
3. hubot adds coffee-script@^1.7.0 to peerDependencies (for running)
4. generator app adds coffee-script@^1.7.0 to dependencies (npm v3 compat)
5. generator script adds coffee-script@^1.7.0 to devDependencies (for testing)
6. generator script adds coffee-script@^1.7.0 to peerDependencies (for running)

B

1. hubot bumps lock from coffee-script@1.6.3 to coffee-script@^1.7.1
2. Leave the app generator as is; no dependency on coffee-script
3. Add coffee-script@^1.7.1 to devDependencies in the script generator

---

Pros (A)

• It ensures only one version of coffee-script gets installed
• npm will warn users on install if a script they've added isn't compatible
  • Potentially fixable by changing the app version constraint (user action, post generation)
• It leverages peerDependencies correctly in an npm v3 world

Cons (A)

• If a script requires a different version of coffee-script both dev and peer deps need updating...
  • ...but still only as bad as the current hubot@2.x peer/dev deps

Pros (B)

• Less changes

Cons (B)

• Multiple versions of coffee-script installed
  • Last script to be installed gets it's version of coffee-script used (unpredictable, as current)
• Not clear that script needs a non-dev dep adding to use a never version outside of tests

---

Both approaches will require that the version specified by hubot and the app/ script generator stay in sync going forward, but I see no way to avoid that since new scripts should be testing against whatever hubot is currently requiring. However this should be palatable as the only reason I can forsee for another version change is a major bump of coffee-script which will require more work than just this anyway.

[mal]

Given the feedback provided in npm/npm#7569 it would seem to me that A is the way to go. It offers the most flexibilty while ensuring compatability between hubot and installed scripts, and also that the version of coffee-script is idempotent (rather than just the version used by whatever script happens to be last in package.json).

@technicalpickles if that makes sense to you, I'd be happy to cook up some pull requests for the outlined changes?

[strugee]

This seems like a very bad idea. What exactly is wrong with having multiple CoffeeScript versions installed? Hubot modules should directly declare their dependencies in package.json instead of relying on an implicit global dependency in Hubot core - this'll only lead to version hell which npm is designed on purpose to prevent.

[strugee]

As a concrete example changes like #86 or even just bumping the coffee-script version - this will create all sorts of breakage outside of Hubot core, which is where it should stay. See also http://module.party/

[technicalpickles]

There's nothing wrong per se with having multiple coffeescript versions installed. The problem is that at some point, one coffee executable is run:

• bin/hubot (generated from this repo) calls bin/hubot (from github/hubot)
• bin/hubot from github/hubot has #!/usr/bin/env coffee

hubot relies on coffee-script having been required, which makes it possible to require coffee files. Many hubot packages are just coffee script files, rather than transpiled javascript.

If there are incompatibilities with the version of coffee script you run in your instance of hubot, and a package you depend on that are .coffee rather than transpiled, then you are going to have problems. I believe that peerDependency at least solves that problem.

A better, longer term solution would be encouraging script packages to transpile to javascript, but that is a bigger thing.

[strugee]

Ah right. That makes sense, thanks.

I guess this issue is more of a bandaid then - the long-term solution being getting module authors to transpile their stuff.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.