Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented Jul 6, 2016

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 jasnell added the semver-major PRs that contain breaking changes and should be released in the next major version. label Jul 6, 2016
@nodejs-github-bot nodejs-github-bot added url Issues and PRs related to the legacy built-in url module. build Issues and PRs related to build files or the CI. punycode Issues and PRs related to the punycode module bundled in Node.js. labels Jul 6, 2016
@jasnell jasnell changed the title punycode: deprecate internal punycode module punycode: deprecate punycode module Jul 6, 2016
@jasnell
Copy link
Member Author

jasnell commented Jul 6, 2016

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

@mscdex mscdex removed the build Issues and PRs related to build files or the CI. label Jul 6, 2016
@jasnell
Copy link
Member Author

jasnell commented Jul 6, 2016

@nodejs/ctc


module.exports = punycode;
const util = require('internal/util');
util.printDeprecationMessage('The punycode module in core is deprecated.');
Copy link
Contributor

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?

@silverwind
Copy link
Contributor

LGTM with suggestion.

@Fishrock123
Copy link
Contributor

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
Copy link
Member

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

@trevnorris
Copy link
Contributor

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

@rvagg
Copy link
Member

rvagg commented Jul 7, 2016

lgtm, one less thing to expose

@ChALkeR
Copy link
Member

ChALkeR commented Jul 7, 2016

@jasnell Will check a bit later today.

@jasnell
Copy link
Member Author

jasnell commented Jul 7, 2016

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
Copy link
Contributor

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
Copy link
Member Author

jasnell commented Jul 7, 2016

@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
Copy link
Contributor

Fishrock123 commented Jul 7, 2016

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
Copy link
Member Author

jasnell commented Jul 7, 2016

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
Copy link
Member Author

jasnell commented Jul 25, 2016

ping @nodejs/ctc

@jasnell
Copy link
Member Author

jasnell commented Jul 25, 2016

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

@ChALkeR
Copy link
Member

ChALkeR commented Jul 25, 2016

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

@bnoordhuis
Copy link
Member

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
Copy link
Member Author

jasnell commented Jul 25, 2016

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.
@jasnell
Copy link
Member Author

jasnell commented Jul 25, 2016

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
Copy link
Member

ChALkeR commented Jul 25, 2016

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

@jasnell
Copy link
Member Author

jasnell commented Jul 25, 2016

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
Copy link
Member

ChALkeR commented Jul 27, 2016

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
Copy link
Member Author

jasnell commented Jul 27, 2016

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
Copy link
Member

srl295 commented Jul 27, 2016

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

@srl295 srl295 added the i18n-api Issues and PRs related to the i18n implementation. label Jul 27, 2016
@ChALkeR
Copy link
Member

ChALkeR commented Jul 27, 2016

@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
Copy link
Member Author

jasnell commented Jul 27, 2016

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

@yorkie
Copy link
Contributor

yorkie commented Jul 28, 2016

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

@jasnell
Copy link
Member Author

jasnell commented Aug 1, 2016

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

@jasnell jasnell closed this Aug 1, 2016
jasnell added a commit that referenced this pull request Aug 3, 2016
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>
@Trott Trott removed the ctc-agenda label Oct 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n-api Issues and PRs related to the i18n implementation. punycode Issues and PRs related to the punycode module bundled in Node.js. semver-major PRs that contain breaking changes and should be released in the next major version. url Issues and PRs related to the legacy built-in url module.
Projects
None yet
Development

Successfully merging this pull request may close these issues.