Tracking Issue: Node.js 9.0.0

[jasnell]

@nodejs/collaborators @nodejs/ctc,

It feels like only yesterday that I was preparing the 8.0.0 release! Time flies!

I plan to begin working on the 9.0.0 release in early September, with an eye towards release by the end of October. The v9.x and v9.x-staging branches will be cut the first or second week of September, with an estimated semver-major freeze by September 30th. Beta releases will be cut once per week in September, with a roll over to RC's in October. I'd really like to avoid last minute major updates so please try to get any semver-major updates, significant dependency updates, etc in by the September 30th deadline.

For any PR that needs to land for 9.x, I would appreciate if you would assign it to the 9.x milestone for easier tracking.

/cc @nodejs/release

[AndreasMadsen]

I think we should remove the async_hooks deprecated API in this release.
/cc @nodejs/async_hooks

[JacksonTian]

I think we should remove the sys deprecated module in this release.

[seishun]

I think we should revisit Buffer constructor deprecation in this release.

[Trott]

I think we should remove the sys deprecated module in this release.

Why? What harm does it do to leave it there?

[refack]

I think we should remove the async_hooks deprecated API in this release.
/cc @nodejs/async_hooks

#14414

[benjamingr]

What version of V8 is this release going to ship?

[targos]

@benjamingr It will be 6.1 or 6.2

[SteveCruise]

Will then it support import/export?

[XadillaX]

I would like to deprecate tls.parseCertString() in runtime via #14249

[JacksonTian]

@Trott

commit b28e700ebdf6583364fec3171390a24153f79632
Author: Ryan Dahl <[email protected]>
Date:   Mon Jan 9 12:59:26 2012 -0800

    require('sys') now throws
    
    To be removed in v0.9

It's planed in v0.9, so I think remove it at 9.x is make sense.

[addaleax]

@JacksonTian The commit you are referencing was reverted, the current state of deprecation has been introduced in dc42e1f (2015).

[Trott]

The cost to us of keeping sys around is nearly zero and is surely less than the cost to end users if we were to remove it entirely.

For some historical background:

The idea that we are probably never going to remove sys entirely has been the position of the project since deprecating, and I don't think anything has changed that would alter that.

From January 2015 when sys was run-time deprecated, @bnoordhuis addressing the issue of when sys will be removed altogether:

Probably never. It's not broken and it's not a maintenance burden. Even a deprecation message is somewhat debatable but deprecation messages can be disabled if you really must; at least it shoos people away from using 'sys' in new code.

That sentiment is echoed by @piscisaureus, @chrisdickinson, and @indutny in the Technical Committee meeting just prior to that where the issue was discussed.

[refack]

Probably never. It's not broken and it's not a maintenance burden. Even a deprecation message is somewhat debatable but deprecation messages can be disabled if you really must; at least it shoos people away from using 'sys' in new code.

That sentiment is echoed by @piscisaureus, @chrisdickinson, and @indutny in the Technical Committee meeting just prior to that where the issue was discussed.

So, I see a hidden cost in above statement — people who use sys and are comfortable with it's use might decide to use --no-deprecation CLI arg, thus hiding other, more "significant" warnings... (yes I know I'm reaching here)

[ronkorving]

I think there is the cost of confusion. People who read code that uses sys for the first time, will be (rightfully) confused and will now be expected to go and look up to see what's right according to the Node manual. It's that, or stay confused. Or worse: assume the wrong answer.

I for one want Node to be intuitive as well as easy to understand.

[Trott]

@refack @ronkorving Those are interesting points worth considering, although I hesitate to encourage the marshaling of more hypothetical downsides. I think these largely-hypothetical concerns are overruled by the concrete concern of breaking working user code for no tangible gain.

• I'm unaware of any evidence that a lot of people are running with --no-deprecation to avoid sys deprecation warnings. (For example, it does not seem to come up a lot on StackOverflow or any of our repos.)

• I'm unaware of any evidence that people are confused by the existence of sys. (For example, it doesn't seem to get asked a lot on StackOverflow or any of our repos.)

• Without evidence that these are problems users are actually experiencing rather than interesting hypotheticals, these are arguments for theoretical purity.

• In contrast, it is relatively straightforward to find code in the wild that currently works but that will break if we remove sys. Even if only a small fraction of that code is truly being run by users currently and isn't a false positive, the cost to end users is significant. (This is doubly so if there are users of the code who would not know how to fix it. Triply so if the author no longer maintains said code.) Here's code published 5 hours ago that uses sys.

• Given the cost to maintainers is near zero, I see no reason to break the code of existing real-world users. If a deprecation warning is not sufficient to move them, then we should leave them alone. (The assessment would change, of course, if this were a significant maintenance burden, a security risk, a buggy module, or something that otherwise inhibits the project. It is none of those.)

[addaleax]

Quoting 539f4c0#commitcomment-23478657 by @davidmurdoch:

I'm just hoping for a "Here's whats going to break when you upgrade:" list of .messages that change. I hadn't really taken a good look at other error message changes, but it looks like most of the .message strings will be changing, so maybe this specific list of which changed and which stayed the same won't really be necessary, as we'll all need and want to update most of them anyway to check the .code anyway.

It would probably be nice to compile a list of changed error messages for this release.

[Trott]

Speaking of the new internal errror stuff...

I've been neutral on it lately, but I'm starting to wonder more and more if it's worth it.

As I see it, here are the upsides:

• Provides users with a persistent identifier for errors. Seems good to me.

• Creates the possibility of one day not having message changes be breaking changes, although no guarantee there. (I consider this a very small benefit. It is not a benefit to our users, really. It is a benefit for us. To me, the burden of having to treat error messages as breaking changes has not been a significant problem given that we release a new major every six months.)

The downsides:

• Additional complexity for our errors.

• A whole bunch of breaking changes just to get the thing implemented. (Ecosystem impact is hard to gauge here, but it may be large.)

• Once we add the code property to errors, we may be stuck with it forever. Once there is significant usage in the ecosystem, it's game over. We can never back out of this system.

I'm not going to object to it unless there are others who feel that way (and even then, I might not object anyway). But as far as I know, there isn't anyone who's uncomfortable with it. But if I'm wrong about that, get in touch, will you? (If there's concern, it would be much better to raise it earlier rather than trying to do it at the last minute. As far as I've been able to tell, no one is concerned except me, and I'm only a little bit concerned.)

[refack]

It would probably be nice to compile a list of changed error messages for this release.

I'm working on it, as per @ljharb's idea, to write an npm package that will do Error message to Error code mapping (#13937 (comment))

[ljharb]

@refack I'm happy to help with any difficulty you have making it backwards-compatible as far back as possible!

[evanlucas]

@Trott I have been a little concerned myself. I think one of the big changes that hasn't really been mentioned is the fact that the code property is no longer writable... I saw err.code = 'some string' just the other day.

[tniessen]

Provides users with a persistent identifier for errors. Seems good to me.

I think this outweighs the downsides, unless there is an alternative with the same advantages and without the downsides. Most other programming frameworks provide mechanisms to distinguish errors more or less precisely, and we were really falling behind with very few error classes and relying on error messages. I like how we did not go the JAVA way (I think there are about 400 exception classes in the JRE), especially since JS does not allow to catch only specific errors, and I don't really see an alternative to our approach.

[addaleax]

@nodejs/npm It might be good to know, what’s your current schedule for future major npm versions? Is there anything we should be planning for/expecting in time for Node 9?

[refack]

#12794 should be in

[refack]

Ping @jasnell @nodejs/release
Any RC planned?

[jasnell]

Yes, planning got out of whack due to Interactive and a surprise customer engagement this week (darned day job!) ... will be getting the RC out as soon as possible this week but struggling to find time.

[apapirovski]

@jasnell I believe this can now be closed but let me know if I've made an error or just reopen yourself :)