refactor: use node: like module specifier for built-in modules.

[Cecil0o0]

node: prefix used to distinguish whether module is builtin or not, such as module specifier "node:url" represents module "url" inside the Node.js instead of outside.

The problem is that use legacy ambiguous module specifier for built-in module, there is a bit more fasion specific way to specify a built-in module, and which is recommended by Node.js also, like below:

such as code from Node.js official website.

and code(in comments) from DefinitelyTyped project.

Here source code at https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/node/url.d.ts#L6

This pr would like to fix that above for improving a bit more readability of module specifier of built-in modules

This pr would like to make them obviously for representation as built-in modules of Node.js, instead of modules from some registry by package manager.

[bpasero]

Hm, but if we decide that is the right way forward, this would have to be changed across all our TypeScript files including extensions? Thats a ton of files to go through 🤔

[mjbvz]

@bpasero I believe we can use both styles of import side-by-side. The main benefit I recall is that node: imports can be resolved faster and more consistently, but I'm not sure if this actually applies to our code

Not sure it's worth making a widespread effort to adopt right now though

[Cecil0o0]

After read comments, I feel sorry for my unclear description for this pr in my first comment above, I just modified the content, for convenience reason, the main changes and relative reason were concluded below:

change:

reason: legacy changed into ambiguous. In my opinion ambiguous make readability of module specifier worse, I may not recognize this module where come from, from Node.js or a module registry until to check with the relative package.json or package-lock.json.

On the other hand, legacy potentially means thing already occurred or done, I don't mean that.

change:

reason: fix word is not very appropriate because we also can use both styles of import side-by-side. Actually I hope to make built-in module specifier that I have already saw, more obvious or specific.

the scope of this pr may only involve the files that I have already saw, not bigger scope at the moment when I created the pr.

[mjbvz]

Thanks for following up @Cecil0o0

It sounds like this change is being made for style reasons. I don't think there's enough benefit to make this change. We may revisit this with a larger pass in the future but this is not a priority at this time