James M Snell

... that would allow it to be used in other Node.js versions that do not have it built in.

We are currently discussing whether or not to backport the impl to Node.js 6.x and I am exploring a standalone polyfill impl...

... matches the API and implementations currently available in browsers and has equivalent performance.

While the old url.parse() and url.format() impls are still there are won't be going anyway any time soon, the new impl is more robust...

so..... NodeConf Fresno ... or FresNodeConf ... ? Decisions decisions... Stay tuned. /cc @MylesBorins @mikeal

It will be important to modify that code to take the included [ERR_CODE] bit into consideration.

It could, however, have an impact on things like tests. For instance, if you use assert.throws() and pass in a regex as the error checker.

This will make referencing and search for error information easier, and will allow us to stop treating message changes as semver-major

The end goal is to provide stable, static error codes that do not change even if the error message does.

It's going to take some time before all Node.js errors have these codes assigned.

And are included in the stack trace of error messages, e.g. "AssertionError [ERR_ASSERTION]: Some Message"

We are starting to incrementally assign error codes to every error. These are accessible via a `err.code` property on the error object

Whole home wifi systems.... any recommendations?

Not passing a callback function has been deprecated and previously would emit a deprecation warning.