punycode: deprecate punycode module

[jasnell]

Checklist

• make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

punycode

Description of change

Currently, the punycode module is used in exactly one spot within core (the url parser). With the recent switch to using the much faster ICU based punycode implementation by default, the punycode module is now only used when node happens to be built without ICU. This change moves the punycode module to internal/punycode and hard deprecates require('punycode').

When the new WHATWG URL implementation lands, users will have access to the URL.domainToUnicode() and URL.domainToASCII statics that are defined as part of the standard interface.

The next step (in the next major) is to remove require('punycode') entirely and make it so that internal/punycode.js is only included if the Node.js binary is built without ICU.

Why? - (a) we do not maintain or support the punycode module, (b) it's 10x slower than the ICU based implementation, (c) we use it exactly once currently, (d) there are userland options, (e) deprecating and eventually removing reduces overall core API surface area.

[jasnell]

@ChALkeR ... would you be able to do a search to see how much of any impact this would have on the ecosystem?

[jasnell]

@nodejs/ctc

[silverwind]

Should we suggest the npm package?

[silverwind]

LGTM with suggestion.

[Fishrock123]

Can we expose this functionality to ICU in a way that isn't hugely breaking? That would seem to be the best route as this functionality is useful, and having it from ICU without a native add-on could be a plus.

[bnoordhuis]

LGTM. I think @silverwind's suggestion is a good one.

[trevnorris]

I assume that URL.domainTo*() will be available before punycode is removed?

[rvagg]

lgtm, one less thing to expose

[ChALkeR]

@jasnell Will check a bit later today.

[jasnell]

That's the intent, yes. I already have both implemented in my whatwg URL PR.
On Jul 6, 2016 11:27 AM, "Trevor Norris" notifications@github.com wrote:

I assume that URL.domainTo*() will be available before punycode is
removed?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#7552 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAa2eeUXcX1jwvydtrNaFV0DA7voIiAgks5qS_OcgaJpZM4JFpPr
.

[Fishrock123]

I'd still like to know why we don't just continue exposing it but with an ICU-backed implementation?

... May I remind people that we can't even get rid of sys? it should surely go before this.

[jasnell]

@Fishrock123 ... we could replace parts of it, yes. There are a couple of extraneous functions exposed that we'd have to reimplement if we were to go that route. Just don't see the point tho, for those people who happen to use the punycode module, they can easily keep on using it from npm.

If it makes things easier, we can do a soft-deprecation in v7 and only do the hard-deprecation in v8.

[Fishrock123]

for those people who happen to use the punycode module, they can easily keep on using it from npm.

You don't even need to use npm to use the util module.

Sorry, I don't buy that we can just get rid of the module unless we have clear data that says literally no-one uses it.

cc @ChALkeR I suppose.

[jasnell]

See: #7552 (comment) and #7552 (comment)

Note that this PR does not remove the punycode module at this time. It simply deprecates it for v7

[jasnell]

ping @nodejs/ctc

[jasnell]

Putting on the ctc agenda to see if we can get resolution.

[ChALkeR]

Argh, totally forgot about this, sorry. Will post some stats today =).

[bnoordhuis]

For the record, while the PR technically LGTM last time I looked at it, the punycode module itself never bothered me. It does the one thing it does well and we hardly ever get bug reports for it.

Replacing it with a ICU-backed implementation is kind of meh, IMO. That would break something that isn't broken in non-ICU builds.

[jasnell]

In non-ICU builds, the punycode module is still used so nothing breaks there. I could make it so that the hard deprecation notice is not printed in non-ICU builds if that would be better.

[jasnell]

Updated the PR so that the deprecation notice is only printed if the build includes ICU, this way non-ICU builds are not affected.

[ChALkeR]

@jasnell — https://gist.github.com/ChALkeR/6dc79b79918f7728659fbc28c5723961. That's a bit old, though, I could make the new dataset today or tomorrow if needed.

[jasnell]

Quite a few hits... thank you @ChALkeR ...
@nodejs/ctc ... given the number of hits, it would make sense that if we're going to deprecate, we do so first with a soft deprecation first in v7 then look at a hard deprecation later in v8.

[ChALkeR]

Note that there is a punycode package on the npm. Not sure if it's compatible, but if it is, it could simplify things.

Upd: I somehow missed that this was already mentioned above =).

Upd2:b77eb8c — both internal and npm module seem to be identical, v2.0.0.

[jasnell]

The punycode module on npm is an updated version of what we ship in core. It's API is compatible as far as I can tell.

[srl295]

the punycode module on npm is by (and CC:) @mathiasbynens

[ChALkeR]

@jasnell Btw, the punycode module has 5 736 456 downloads per month. This could indicate that most of that require('punycode') are actually already using the module, or this could indicate that a lot of people are using both of those =).

Btw, punycode is marked as being Stability: 2 - Stable. So +1 on soft deprecation first.

[jasnell]

Discussion by the CTC would be to soft deprecate in v7 and revisit hard deprecation prior to v8.

[yorkie]

@jasnell this might close #7401 as a side-effect :-)

[jasnell]

Closing this PR in favor of #7941
Hard-deprecation of the punycode module will be revisited post v7