Uh oh!
There was an error while loading. Please reload this page.
util: expose the WHATWG Encoding API globally - #20662
Conversation
This commit makes `util.TextEncoder` and `util.TextDecoder` available on the global object.
| configurable: true, | ||
| enumerable: false | ||
| } | ||
| ); No newline at end of file |
There was a problem hiding this comment.
This needs a new line at the end
AyushG3112
commented
May 10, 2018
Personally, I don't like the idea of polluting globals. That aside, in this case, I have a particular concern: the names are too ambiguous and potentially confusing to users. I would prefer defining 2 classes on the |
devsnek
commented
May 10, 2018
@AyushG3112 the names and global-ness are part of whatwg spec: https://encoding.spec.whatwg.org |
AyushG3112
commented
May 10, 2018
@devsnek I see, thanks for the link! |
vsemozhetbyt
commented
May 10, 2018
Thank you. doc/api/intl.md also needs updating as well as all posible cross-links inside our docs. |
vsemozhetbyt
commented
May 10, 2018
|
| added: v8.3.0 | ||
| changes: | ||
| - version: v11.0.0 | ||
| pr-url: https://github.com/nodejs/node/pull/TO_DO |
| <!-- YAML | ||
| added: v8.3.0 | ||
| changes: | ||
| - version: v11.0.0 |
There was a problem hiding this comment.
I'm not sure this should be specified here, I think we use a placeholder that gets filled in later?
There was a problem hiding this comment.
Same for the other v11.0.0 uses in this file and globals.md.
| see [Custom promisified functions][]. | ||
| ## Class: util.TextDecoder | ||
| ## Class: TextDecoder |
There was a problem hiding this comment.
I think this is confusing if util.TextDecoder is still accessible.
There was a problem hiding this comment.
@mscdex I did this for consistency since, in the url docs, the class heading is URL instead of url.URL: https://nodejs.org/dist/latest-v10.x/docs/api/url.html#url_class_url
But I agree with you that this is confusing. In the case of URL, it fits the url docs. In the case of TextDecoder, it doesn't intrinsically fit the util docs.
So I'm gonna change this here, and also follow your suggestion of moving the TextDecoder and TextEncoder docs from util to globals (see: #20662 (comment)).
There was a problem hiding this comment.
@mscdex Actually, I'm not quite sure about this. All the globals in globals.md link to other docs, so globals is, in effect, some kind of meta documentation. If I'd move the encoding docs to globals, 90% of the globals documentation would be about encoding, which might be confusing, too. So I don't think is a clear-cut issue.
In fact, I think there are 3 possibilities here:
[1.] Keep the encoding documentation in util and link to it from globals.
pro: Keeps the old documentation structure so people that know the docs already won't be surprised.con: When searching for "encoding", "text encoding" or similar terms, people are less likely to find the documentation (since the words "globals" and "utilities" are not semantically related to "encoding").
[2.] Move the encoding documentation to globals and link to it from util.
con: Theglobalsdocs are currently "meta documentation" in that they only link to other, more detailed documentation. Moving the encoding documentation into this section would break with that.con: As explained in[1.], when searching for "encoding", less experienced people might not look in the "globals" documentation, making it less likely for them to find the correct documentation.con (maybe): This could possibly make navigating theglobalsdocs harder in the future, for example, if new globals are introduced that would occur below the lengthy encoding documentation.
[3.] Move the encoding documentation to a new documentation section, e.g. encoding / "Encoding" or text-encoding / "Text Encoding", and link to it from util and globals.
pro: This would perhaps make finding the correct documentation easier for less experienced people.con (maybe): Documentation-table-of-contents-bloat (if such a thing exists). 😄
In any case, I'm not sure what's a good way to proceed with this. So I'd greatly appreciate more feedback regarding this issue.
PS: When I go to https://nodejs.org/dist/latest-v10.x/docs/api/, I sorely miss a tiny search-box in the top-right corner - I think that would help a lot.
There was a problem hiding this comment.
For overall doc search, you can use "View on single page" variant, there is a link at the top of each doc.
There was a problem hiding this comment.
@vsemozhetbyt True, but I don't think that's a friendly UX/DX. (Especially on mobile, loading the whole documentation on a single page might not be the best option. But then again, I think this is off-topic here.)
| <!-- type=global --> | ||
| The WHATWG `TextEncoder` class. See the [`TextEncoder`][] section. |
There was a problem hiding this comment.
If what we're doing is migrating from util to a global, I think it'd be better to have the reverse: document here and have util.TextEncoder link to the definition here.
cjihrig
left a comment
There was a problem hiding this comment.
LGTM once all of the comments are addressed.
| <!-- YAML | ||
| added: v8.3.0 | ||
| changes: | ||
| - version: v11.0.0 |
There was a problem hiding this comment.
Same for the other v11.0.0 uses in this file and globals.md.
Trott
commented
May 12, 2018
@vsemozhetbyt I think it is. In my experience, new globals cause failures in some test suites (particularly the one associated with hapijs...not sure if it's code or lab that breaks but one of them, and not sure it actually breaks anymore when a global is added, but it sure used to). Maybe the thing to do is run CITGM and see if anything breaks. I'm going to label this
|
Trott
commented
May 12, 2018
@nodejs/tsc Take note. This adds to the |
cjihrig
commented
May 12, 2018
It's lab. lab detects leaked global variables by checking a list of known globals. So, when Node adds a new global, it also requires an update to lab. |
Trott
commented
May 12, 2018
Given that once this changes lands, it will break a whole lot of test suites until the owners update, I think it's definitely semver-major. I'm also adding a |
jasnell
commented
May 12, 2018
Adding a new global is always semver-major |
MarkTiedemann
commented
May 13, 2018
@cjihrig I'm kind of confused about this. Would you mind sending me a link to the lab that you are referring to or giving me a short explanation of what the lab is? Also, does this have any implications for this PR? Should I make changes to the lab, too? And if so, could you guide me to where these changes are required? |
cjihrig
commented
May 13, 2018
lab refers to https://www.npmjs.com/package/lab. It's a test runner used by the hapi.js ecosystem. The addition of a new global variable will cause it's global leak detection to fail, which is one reason why new globals have to come in a semver major release. |
MarkTiedemann
commented
May 13, 2018
@cjihrig Thank you for the explanation! I created a tiny heads-up PR in |
| if (global.TextDecoder) { | ||
| knownGlobals.push(TextDecoder) | ||
| } |
There was a problem hiding this comment.
If these values are added to the global, they should not be checked for. Instead, they should be added to let knownGlobals = [ ... on top. And I guess common/index.js has to be changed as well?
There was a problem hiding this comment.
I agree, they should not be checked for conditionally. So I'm gonna add TextEncoder and TextDecoder to knownGlobals in both test/common/index.mjs and test/common/index.js.
Thanks for the feedback, @BridgeAR!
On another note, I think the recently added URL global should be added to both arrays, too (but I guess in another PR).
BTW, the globals are only added in the following case:
constbrowserGlobals=!process._noBrowserGlobals;if(browserGlobals){// ...}I could not find any documentation regarding this, except that there was once a --no-browser-globals flag, which doesn't seem to work anymore.
λ node --no-browser-globals
node: bad option: --no-browser-globals
So I assume I could remove these 2 lines, too?
EDIT: I found out I can't remove these 2 lines. The no-browser-globals mode can be turned on with configure --no-browser-globals and (...) is not officially supported for regular applications, but still supported after all.
TimothyGu
commented
May 16, 2018
| setTimeout | ||
| setTimeout, | ||
| TextDecoder, | ||
| TextEncoder |
There was a problem hiding this comment.
I made a mistake in my review earlier. By adding these non-enumerable values we actually do exactly the opposite of what is required in this test. Please remove them and just keep the common files as they were therefore. See #20717 for further details.
TimothyGu
commented
May 18, 2018
MarkTiedemann
commented
May 21, 2018
The tests are failing because the globals are not set, as they should be. But I haven't figured out why yet. I'd appreciate any help for fixing this. - value: undefined,+ value: [Function: TextEncoder] |
MarkTiedemann
commented
Sep 17, 2018
Superseded by #22281. |
This PR makes
util.TextEncoderandutil.TextDecoderavailable on the global object.Currently, this is work-in-progress, but I am looking for feedback.
See: #20365
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes