2.3.0 no longer installs on older npm versions #1867
Comments
|
Looks like an oversight. I'll get on this |
|
@dougwilson released as v2.3.1 |
|
@dougwilson do you know offhand which is the first version of npm that supports the caret? |
|
It was added in npm 1.3.7, I believe. This means it was first available as part of the Node.js 0.10.16 bundle (previous versions on Node.js didn't provide out-of-the-box support for the caret). |
|
Well, thank you for the update, but it looks like 2.3.1 still doesn't work, because there are some new sub dependencies on 2.3.0+ that are using the carets, for example, something is trying to install |
|
Honestly I have no idea what to do about that. |
|
The only solution here is to stop supporting people with just a minor release (not semver compliant, I know), or replace the lodash.create dependency altogether with a dependency that works on the same platform. The usage of lodash.create in the PR is dubious, as Node.js provides the feature in util.inherits out of the box. |
I'm not sure I understand this suggestion; can you reword? It sounds like the only way out of this is:
Right? I mean, we simply can't use Since npm < v1.3.7 doesn't support carets, the only way you would have noticed this issue is if your Mocha dependency is set to |
|
I noticed this issue because I wanted to upgrade to mocha 2.3.0, not because it suddenly broke for me :) And yes, I don't have control over the version on npm on things like HP Helion (formally Stackato). That PaaS version I have available for Node.js work can use any version of node, but is stuck on only npm 1.3.5, and I don't have control over getting it upgraded. This does not only mean I cannot upgrade to mocha 2.3.0, but also signals that I'm going to have to abandon mocha very soon if I want any updates at all, correct? |
|
@dougwilson It'd be unfortunate if you abandoned Mocha. A question that needs answering is: do we hold Mocha back by refusing to use any dependency (or dependency-of-a-dependency) which happens to use a caret in its I don't think that's good for this project. Do you agree? Alternately, do we commit to patching old minor versions, and add the overhead of maintaining separate branches? I'm almost certain we don't have enough resources to handle that. Have you attempted to contact HP? |
|
The latest version of HP Helion has an updated npm, I believe, but corporate upgrade timelines are not close; I would not expect corporate to upgrade for at least another 6 months, so until then, I have no option.
It depends on how much you care about supporting your user base. I maintain dozens of modules and none of them have a caret in their dependency tree, not only because companies still need support for this, but also because having carets in your dependency tree makes it that much more likely mocha will break overnight by an update of some sub sub sub dependency. |
|
If you look in your bundle file, you already have a dependency that is using the Node.js util.inherits. Why not just use that? |
|
Anyway, I have provided as much feedback as I can, I believe: the issue is I can no longer install 2.3.0 on the same setup I could install 2.2.x on, which is a bit lame. |
Mocha supported NodeJS v0.4.x until recently. Historically, I think we're pretty sensitive to backwards compatibility. However, I am not sensitive to the needs of large, slow-moving corporations, simply because I have no experience with them. I hope if this situation arises in the future, you can notify us. Better yet, planning ahead will serve us both better. So I think what I'd like to do is use I don't anticipate any new dependencies before v3.0.0 that would involve carets. I think we can safely put the kibosh on that. Mocha v3.0.0 may or may not follow the same guidelines. Sound fair? |
|
If this sounds good, I'll release again tomorrow so you can check things out on Tuesday, because you won't be working tomorrow, right?? 😄 |
|
That sounds fair, but also if you so desire to do nothing, that is also fair, because I leave the decision to you, as you are an owner of the module, and I am simply a random commenter :) Thank you for your attention on this, and though I may be the first to bring it up, I bet many more developers lay in silence oj these kinds of issues, either simply sticking to some old version of mocha, using some other testing project, or simply not writing tests at all (because, well, who cares about testing). The main thing about testing frameworks, imo, is that they need to have the largest backwards support of anything, because if you have some software that you want to support Node.js 0.6 with, well, you have to have a test runner that also functions under Node.js 0.6 (currently I use mocha 1.x for that). |
|
What's tough is that we're pretty blind to knowing how many users are trying to run Mocha under NodeJS 0.6 (for example). Basically all we can do is ask in here and our Google group, and if nobody pipes up (and nobody does), then we just figure nobody cares enough. If you have any suggestions on how we can gather that information and make more informed decisions about when to drop support for x, I'm all ears. |
I agree it I a hard problem I have struggled with myself. Typically no one ever speaks up until they find their support is gone :/ I did a lot of Perl 5 open source years ago and the versions to support were obvious: all versions 5.6+. When I started with Node.js back at the end of 2009 it was a mess and then 0.6 came out, it was painful, we upgraded, settled on 0.6 minimum, and it stayed that way for long enough that even yo this day there are supported OSes that come with 0.6. The minimum is a hard choice these days, and personally I support 0.8 unless I can get away with also supporting 0.6, then I will. 0.10 has been out for s long and has nice things compared to 0.8 (like streams2) I am getting more and more tempted to start making 0.10 my go to lowest. The problem right now, though, is there is nothing above 0.10 except for 0.12, which has a broken v8 version, and io.js which does not have the name buy-in to make corporate even consider it (especially when it's still iffy about Node.js itself). And I guess /rant 😁 |
* master: (25 commits) Fix mochajs#1798: Correctly attribute mutiple done err with hooks Remove redundant harmony flag Cast non-string return values from err.inspect() Call the inspect() function if message is not set Revert jade to support npm < v1.3.7 Fix eqeqeq linting errors from eslint 1.4.0 release Fix mochajs#1669: catch uncaught errors outside test suite execution Support all harmony flags Fix fragile xunit reporter spec Fix linter warning "Expected a conditional expression and instead saw an assignment" Stackfilter fix: Don't remove modules/components from stack trace in the browser Fix mochajs#1864: xunit missing output with --reporter-options output Fix 1875: Markdown reporter exceeds maximum call stack size IE<=8 no [].reduce, so use 'utils.reduce' instead Release v2.3.2 remove lodash.create; closes mochajs#1868 update package.json & component.json for v2.3.1 update HISTORY.md fix package.json to use exact version of lodash; closes mochajs#1867 Fix: Bail flag causes before() hooks to be run even after a failure ... # Conflicts: # lib/runnable.js
Hi! It looks like PR #1753 added the line
"lodash.create": "^3.1.1"topackage.json, which means thatmochano longer installs with versions on npm that do not understand the^specifier. It's also the only non-exact version in dependencies. Can a version be published with that changed to an exact version, please?The text was updated successfully, but these errors were encountered: