Closed graingert closed 8 years ago
+1
npm WARN deprecated to-iso-string@0.0.2: to-iso-string has been deprecated, use @segment/to-iso-string instead.
can you add this to the other updates of mini-match, glob and jade - in v3.0 ???
mocha@2.5.3 │ ├─┬ glob@3.2.11 │ │ └─┬ minimatch@0.3.0 │ ├─┬ jade@0.26.3 │ └── to-iso-string@0.0.2
I'm concerned about dropping support for npm v1.x by requiring a scoped package. I don't have any numbers around what % of npm users are using 1.x.
To summarize:
@segmentio/to-iso-string
will cause npm install mocha@3
to fail if you have npm 1.4.x installed. npm 1.4.x is the current minimum version which can install mocha@3; using a scoped package would increase it to npm 2.x.to-iso-string
; we need to release without a warning.to-iso-string
or otherwise reverse the decision of making it a scoped module.Potential solutions:
@segmentio/to-iso-string
and republishing under another (non-scoped) name to avoid an npm warning. This is loathesome.lib/to-iso-string/
), and add it to VCS. Also not pretty, but probably the "least bad" of the three solutions here from my perspective.Again, it's unclear how many users of npm 1.4.x who cannot upgrade npm for whatever reason would not be able to upgrade to mocha@3. If that percentage was very low--say hovering around 1% of users--then sure. But the earliest version of Node.js v0.10.x that ships with npm@2 is v0.10.44, released in late March.
A few days back I asked @othiym23 if he knew of any straightforward way to get this data; unfortunately, he didn't.
In the spirit of "safely" releasing, I'm gonna say let's do solution 3, but I would appreciate feedback from anyone.
cc @mochajs/core
- I don't want to release v3.0.0 and invite a cascade of PRs addressing the warning that we'll get by depending on "deprecated" to-iso-string; we need to release without a warning.
I’m wondering if we could prevent this issue by commenting on it in the release notes. I mean, if it doesn’t actually cause damage, then maybe this is not that much of a trouble to just go with it. But if this is not acceptable, I’d go with the “potential solution 3.”
MIcrosoft dropped IE10
@anthony-redFox the problem isn't IE8 it's PhantomJS that have a broken implementation
Maybe https://github.com/zloirock/core-js/blob/master/library/modules/es6.date.to-iso-string.js
@graingert PhantomJS has the bug that - Date.prototype.toISOString() does not handle milliseconds below 1970-01-01T00:00:00.000Z link
Are you using a date below 1970-01-01T00:00:00.000Z? any use case?
With the advent of Chrome Headless Mode, Phantom.js hopefully won't be an issue for to much longer. Not this solves the immediate issue..
If you are wondering "why do we support all these old browsers and versions of Node?", consider the nature of test frameworks. You want to be able to write your tests once, run them different platforms, and assert compatibility.
Regardless of whether a vendor drops support for any given browser, if business requirements demand broad browser support, and Mocha drops support for IE8 (for example), then we're going to prevent that user from upgrading (and it's worth noting there's no "LTS" support for Mocha). I wouldn't want to be the person trying to make a business case to drop official support for IE8 because the test framework did. Fundamentally, test frameworks need to offer broader version/platform support than a jQuery or a Backbone.
When it's no longer feasible to support old platforms--and we won't lose too many users--then we will drop support. Mocha v3 will drop "official" Node v0.8 support, and will not be installable in npm < 1.4.x.
It's not too much of a stretch to require npm v2.x since Node ~0.10 now ships with it. What's making me uncomfortable is that we have no hard data that says "very few people use npm < 2" and "of those people, very few can upgrade". npm should not show the warning anyway; if it didn't, this wouldn't be an issue at all.
I'm leaning towards requiring npm v2 just because I don't want to deal w/ the alternatives nor the number of PRs that will come through which would break npm 1.4.x anyway...
I'm also +1 to dropping support for IE8. Nobody is forcing that very small group of people to upgrade and Mocha will continue to work for them fine as is. If it's absolutely necessary we can backport a fix or something.
Every time I was in the case where I was on the other end, where a thing I was using stopped supporting how I was using it, it didn't affect me I was still able to keep using it.
We could put this file and this file into a directory (say lib/to-iso-string/), and add it to VCS. Also not pretty, but probably the "least bad" of the three solutions here from my perspective.
Yeah just copy it for now.
But what are we gaining by dropping IE8 ever is the question I'd ask
I think you should depend on core-js and use their to-iso-string polyfill
On 20 Jul 2016 18:54, "Travis Jeffery" notifications@github.com wrote:
But what are we gaining by dropping IE8 ever is the question I'd ask
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mochajs/mocha/issues/2370#issuecomment-234027970, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZQTOK85jgyyxn_OIQY0LcrZth9vxOqks5qXmC6gaJpZM4JJiYo .
A wide variety of points, recommended courses of action in the first and last items:
Date.prototype.toISOString
and JSON.stringify
... might be the only ones?). To test this conditional-on-polyfill support we'd pull in polyfills as a dev dependency only (so using Mocha to test other libs can't make it seem like they work if they're missing polyfills). Dev dependencies also won't get so many people worrying if we do end up having to use some deprecated but still helpful package.@ScottFreeCode I don't mean to suggest mutating Date.prototype I mean using the library function https://github.com/zloirock/core-js/blob/master/library/modules/es6.date.to-iso-string.js
@ScottFreeCode I like your point about toISOString
is "unlikely to change". This makes the "copying its source" solution more digestable. And I agree that it'll be more difficult to convince users "not to worry" about the warning.
@travisjeffery I guess what I was trying to say is if it's not too hard to offer IE8 (or IE7) support, we should. If it (or any old technology) inhibits Mocha from moving forward as a project somehow, then we need to consider dropping support for that technology. I just don't think we're quite there yet with IE7/IE8.
So, I'm gonna copy it. Let's revisit later.
37fa56483ac29094e974b816918ebb4af38a3b6c
I know it's closed but figured I'd pop in. With npm v4 right around the corner, if you're concerned about lack of scoped package support (maybe in other package) I believe @seldo has npm v1 usage percentages.
Hoping to get some feedback here