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 🤔

@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

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.

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