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
refactor: import timers, process
, and Buffer
from node:
#7157
refactor: import timers, process
, and Buffer
from node:
#7157
Conversation
Co-authored-by: muchnameless <12682826+muchnameless@users.noreply.github.com>
Might be worth configuring the no-restricted-globals eslint rule to disallow the usage of the global |
Co-authored-by: Almeida <almeidx@pm.me>
I'm still missing |
Oh. Good catch, I'll make a PR in a bit. |
@kyranet have you managed to get this fixed yet? People are still hitting issues in our embedded runtime. |
Yes, I just opened #7269 to fix that, sorry for the delay, I have been busy with exams 😅 |
Please describe the changes this PR makes and why it should be merged:
Following this Tweet, this PR imports
process
,Buffer
, and timers (setTimeout
,setInterval
, andsetImmediate
) from their respective modules.But why?
tl;dr: if Node.js recommends a way to do something over another, we abide to that, also known as following best practices.
This has been asked several times in the server, while I do not know the very exact reason (Node.js developers aren't sharing many details in their PRs), I have read the same thing:
The imports tell bundlers (and other tools) where certain globals come from, and what kind they are, for example, Node.js's
setTimeout
isn't a compatible implementation of the DOM one, one returns aNodeJS.Timer
and the other returns anumber
, however, bundlers can't tell if a package needs one or another. Importing timers fromnode:timers
is a sensible approach to this, since it tells the bundler we're using Node.js's.And now my theories...
It's possible that Node.js might look into deprecating some of the globals (specially those that aren't used in other platforms) in favour of importing from a package, this remains to be confirmed, but it's likely.
Also, there's a possibility they also recommend this change to protect libraries from any kind of global mutation, it only takes an inexperienced developer writing
process = something
to trigger a quite funny error to debug. Since the imports are const-assigned, we keep a reference of those global objects during the entire runtime, and as such, this is far less likely to happen, also with ESM, developers won't be able to change the exports of modules, so that's one problem that'll be fixed in the (far) future.For the performance kids, because the globals are now
const
assigned, it's faster than pulling from the global, since the value cannot change.Status and versioning classification: