Repository navigation
Making util.TextDecoder and util.TextEncoder available on the global object #20365
Description
- Version: v10.0.0
- Platform: Microsoft Windows [Version 10.0.16299.371]
- Subsystem: util
Just wondering since the WHATWG URL API was made available on the global object in Node v10.0.0: Should the WHATWG TextEncoder and TextDecoder APIs (that are currectly available via require('util')) be made available on the global object, too, or are there any reasons for not doing so?
PS: If this should be done, I'd love to start working on a PR for it.
Activity
addaleax commentedon Apr 27, 2018
@nodejs/tsc
mcollina commentedon Apr 27, 2018
+1 as semver-major.
jasnell commentedon Apr 27, 2018
+1 as a major
BridgeAR commentedon May 10, 2018
Just as a note: the more we add as globals, the harder it gets to lazy load parts of core to improve startup time and to minimize memory overhead.
MarkTiedemann commentedon May 10, 2018
@BridgeAR I agree with you in general. I do think, however, in this particular case
const { deprecate } = NativeModule.require('internal/util');is called beforeconst { TextEncoder, TextDecoder } = NativeModule.require('internal/util');. Not sure howNativeModule.requireworks internally, but I would expect the second call not to add large overhead. Is that correct?EDIT: Correction:
deprecateis required afterTextEncoderandTextDecoder.BridgeAR commentedon May 10, 2018
See #20567. It is the combination of all those files at startup time. It is not about this specifically (it would be fine as it is right now) but I just want to point out in general that every added global is making it more difficult to load less things on startup. Using getters for the globals would help but at least for console it should not be a getter due to the spec. I do not know if that is also here the case but I guess it is.
util: make TextEncoder/TextDecoder global
util: make TextEncoder/TextDecoder global