I think we've generally avoided these kinds of commits/PRs and preferred to only update them if you're already affecting those variables because of other changes.

@mscdex, thanks for letting me know. Should I then try A) or B) below? Happy to address either way.

A) Revert everything except lib/_http_client.js, which this PR is trying to follow up with the comment in another PR

B) Just close this PR.

I generally have no problem with these kinds of changes when done in batch. Lots of small changes like this get noisy.

i don’t think these changes have more improvements, but add some noisy commits

i don’t think these changes have more improvements, but add some noisy commits

@himself65, while it’s true that there are no major improvements, there is an subtle improvement to use “const” over “var” as it will throw an error to “promote” immutability, if a “const” variable’s value is reassigned after its declaration.

@BeniCheni
this task which change “var” to “const” or “let” should do when refactoring code or add new methods or anything else.
only commit with change “var” is unnecessary i think

@himself65, this is an actual follow-up per a suggestion from another PR, which is an actual change. (could be traced by 1st comment of this PR) The suggestion was to punt the var => let / const to a separate PR.

I guess we might just go ahead and accept a couple PRs like this. Otherwise this is going to come up frequently and as soon as we are through with it, we do not have to worry about it anymore.

I am aligned with @jasnell that we should do this as batched change. It is actually quite simple and straight forward to use eslint to auto fix these. Should we just do that?

Would changes like this make git blame less efficiently ?

@ZYSzys it adds one more step to find the actual author. Most tools I know / use allow to directly jump to the former blame as well, so I personally do not see this as a big downside anymore.

@BridgeAR

It is actually quite simple and straight forward to use eslint to auto fix these. Should we just do that?

I agree this. Also, I think it is better to add no-var rule in eslint so that we won't worry about 'var' anymore. However, I think it needs agreement from some collaborators.

@nodejs/tsc PTAL

Thanks for your time and feedback. I’m closing this PR to avoid potential further confusions.