Mocha: to-iso-string renamed to @segmentio/to-iso-string

[graingert]

[boneskull]

Hoping to get some feedback here

[codeuniquely]

+1

npm WARN deprecated [email protected]: 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 ???

[email protected]
│ ├─┬ [email protected]
│ │ └─┬ [email protected]
│ ├─┬ [email protected]
│ └── [email protected]

[boneskull]

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.

[boneskull]

To summarize:

• There's little left to do before the v3.0.0 release other than updating some documentation.
• Simply upgrading to @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.
• 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 _also_ don't expect @segmentio or @ndhoule to "un-deprecate" to-iso-string or otherwise reverse the decision of making it a scoped module.

Potential solutions:

1. Using a GitHub URL as a dependency is bad due to inconsistencies around npm version support, mutability, another point of failure, etc.
2. Forking @segmentio/to-iso-string and republishing under another (non-scoped) name to avoid an npm warning. This is loathesome.
3. 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.

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

[gurdiga]

• 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.”

[anthony-redFox]

My opinion, solution is drop IE8.
MIcrosoft drop IE8 link
jQuery 3.0 drop IE8 link
Backbone will drop IE8 link
lodash 4.0 drop IE8 link

And mocha 3.0 is good release where can do that.

[graingert]

MIcrosoft dropped IE10

[graingert]

@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

[anthony-redFox]

@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?

[mbrevda]

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..

[boneskull]

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...

[travisjeffery]

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.

[travisjeffery]

But what are we gaining by dropping IE8 ever is the question I'd ask

[graingert]

I think you should depend on core-js and use their to-iso-string polyfill

On 20 Jul 2016 18:54, "Travis Jeffery" [email protected] 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
.

[ScottFreeCode]

A wide variety of points, recommended courses of action in the first and last items:

• Seeing as the ISO date format isn't going to get out of date, I don't really see a reason not to keep a shim in our codebase if we want a shim.
• The web developers deciding whether to upgrade Mocha aren't necessarily the users deciding whether to upgrade their browsers.
• Speaking of not having to update, we can keep using the deprecated to-iso-string package, but convincing our users that it's ok is another matter.
• A lot of people are anxious to get many different updates in Mocha at the moment.
• Testing (what Mocha makes possible!) on IE8 at least is fairly important since it hasn't entirely gone away yet and is one of the few browsers significantly lacking in support for modern web standards anymore.
• Mocha supporting IE7/8 is pretty easy so far, aside from deciding where to get the few shims and having to change the assertion library for Mocha's own tests. Most of the time we spent trying to make it happen was finding a compatible assertion library and getting Karma and Sauce set up; the real code changes were few and simple.
• We currently support IE7 if I'm not mistaken, because we can; but whereas there's a handful of people still using IE8, I'm not sure there's anyone using IE7 anymore.
• Starting with IE8, polyfills on object prototypes work. Thus, if we don't care about IE7 support, an alternative to using shims is just to document that it works on IE8 if the user supplies a couple polyfills (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.

[graingert]

@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

[boneskull]

@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.

[boneskull]

37fa56483ac29094e974b816918ebb4af38a3b6c

[jdalton]

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.