-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
punycode: deprecate punycode module #7552
Conversation
86e752b
to
27cfae2
Compare
@ChALkeR ... would you be able to do a search to see how much of any impact this would have on the ecosystem? |
@nodejs/ctc |
|
||
module.exports = punycode; | ||
const util = require('internal/util'); | ||
util.printDeprecationMessage('The punycode module in core is deprecated.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we suggest the npm package?
LGTM with suggestion. |
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. |
LGTM. I think @silverwind's suggestion is a good one. |
I assume that |
lgtm, one less thing to expose |
@jasnell Will check a bit later today. |
That's the intent, yes. I already have both implemented in my whatwg URL PR.
|
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 |
@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 If it makes things easier, we can do a soft-deprecation in v7 and only do the hard-deprecation in v8. |
You don't even need to use npm to use the 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. |
See: #7552 (comment) and #7552 (comment) Note that this PR does not remove the |
27cfae2
to
6a03329
Compare
ping @nodejs/ctc |
Putting on the ctc agenda to see if we can get resolution. |
Argh, totally forgot about this, sorry. Will post some stats today =). |
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. |
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. |
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 into internal and hard deprecates `require('punycode')`. The hard deprecation notice is only printed in ICU builds. 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 make it so that internal/punycode.js is only included if the Node.js binary is built without ICU.
6a03329
to
7b0c497
Compare
Updated the PR so that the deprecation notice is only printed if the build includes ICU, this way non-ICU builds are not affected. |
@jasnell — https://gist.github.com/ChALkeR/6dc79b79918f7728659fbc28c5723961. That's a bit old, though, I could make the new dataset today or tomorrow if needed. |
Quite a few hits... thank you @ChALkeR ... |
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. |
the punycode module on npm is by (and CC:) @mathiasbynens |
@jasnell Btw, the Btw, |
Discussion by the CTC would be to soft deprecate in v7 and revisit hard deprecation prior to v8. |
Closing this PR in favor of #7941 |
As discussed and agreed upon by the CTC, the punycode module bundled in core is soft-deprecated (docs only) for v7 with an eye towards hard-deprecation in v8 or later. Also see discussion in #7552 PR-URL: #7941 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Checklist
make -j4 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected 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, thepunycode
module is now only used when node happens to be built without ICU. This change moves thepunycode
module tointernal/punycode
and hard deprecatesrequire('punycode')
.When the new WHATWG URL implementation lands, users will have access to the
URL.domainToUnicode()
andURL.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 thatinternal/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.