test: reduce string concatenations

[vsemozhetbyt]

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

test

Refs: #12455

This is not an exhaustive deliverance from all string concatenations: if a result looked too ugly and messy, I've abstained to change, so some concatenations still remain. I am not sure if we should to add prefer-template: error to test .eslintrc.yaml, so I've also abstained from proposing, but let me know if this is discussable.

Concerning reviews: #12735 (comment)

• 01. test: reduce string concatenations (the base commit, with test/common.js only)
• 02. fixup: addons – known_issues, pseudo-tty
• 03. fixup: pummel
• 04. fixup: sequential
• 05. fixup: parallel/assert* – child-process*
• 06. fixup: parallel/cli* – cwd*
• 07. fixup: parallel/dgram* – file*
• 08. fixup: parallel/fs*
• 09. fixup: parallel/http* – http-full-response
• 10. fixup: parallel/http-get-pipeline-problem – http-write-empty-string!
• 11. fixup: parallel/https* – https-drain
• 12. fixup: parallel/https-eof-for-eom – https-truncate
• 13. fixup: parallel/intl* – net*
• 14. fixup: parallel/next-tick* – regress*
• 15. fixup: parallel/repl* – spawn*
• 16. fixup: parallel/stdin* – timers*
• 17. fixup: parallel/tls* – tls-connect*
• 18. fixup: parallel/tls-delayed* – tls-invoke-queued
• 19. fixup: parallel/tls-js-stream – tls-securepair*
• 20. fixup: parallel/tls-server* – tls-wrap-timeout
• 21. fixup: parallel/url* – zlib*

[vsemozhetbyt]

CI: https://ci.nodejs.org/job/node-test-pull-request/7739/

[refack]

Will you be able to activate any eslint rules after this?

[vsemozhetbyt]

@refack There are still ~20 cases like these ones I've abstained to change, at least till I think up some equally readable solutions. But these ones can be addressed with ESLint disabling comments. So prefer-template: error can be added to the test .eslintrc.yaml with a very little churn after this PR.

[refack]

You should add those (rule and comment exceptions) as it would provide extra motivation for this PR.
I'm a big believer better code, but there is code-churn and git history to consider. So IMHO adding an eslint rule will tip the scales in favor of this PR.

[vsemozhetbyt]

I could do this if there is a minimal consensus if we should restrict this aspect from now on. Maybe some liberality is preferred here by the other collaborators)

[refack]

P.S. for things like these ones, I would do a multiline `` with replace

`PUT /this HTTP/1.1Content-Type: text/plainTransfer-Encoding: chunked4ping0`.replace(/\r|\n|\r\n/g,'\r\n')

[refack]

I could do this if there is a minimal consensus if we should restrict this aspect from now on. Maybe some liberality is preferred here by the other collaborators)

Yes, this is only my opinion and I actually want to +1

[vsemozhetbyt]

@refack I've considered this way, but there are nits here concerning indentation, leading/trailing returns and aligning. There are solutions, and maybe some util formatting function can be added to common.js lib, but this also may need to be discussed.

[vsemozhetbyt]

@refack By the way, .replace(/\r|\n|\r\n/, '\r\n') may safely be just .replace(/\n/g, '\r\n'), as per spec in multiline template literals can only be \n regardless of OS, IIRC.

[refack]

@vsemozhetbyt I love 2ality 🥇
As for "weird" situations, just exclude them with comments...

[benjamingr]

I like the change but it's huge which makes it impractical to actually review. I went through the first 20-30 and they look good - but I don't feel comfortable with landing this unless someone goes through all changed content.

[vsemozhetbyt]

Maybe we can divide: a reviewer can write down the last file reviewed, next reviewer can start from the next file.

[refack]

Almost went over all.
A few nits, some suggestions, and request to change path manipulation to path.join

[refack]

This should be path.join

[vsemozhetbyt]

There are many such things in the tests. Should we address them in this PR?

[jasnell]

Separate PR is likely safer.

[benjamingr]

I don't think a path.join is important here, node modules always use / (so it's not an OS compatibility concern). The main advantage of path.join is that it abstracts joining complex paths, for concatenating two strings / should be fine.

That said, if this view is contested - we can just leave it as is in the PR.

[refack]

IMHO if we're touching this, so might as well "fix" it. There are multiple path concatenations done as strings, I feel they should all be changed, as path.join is semantically different, even if string concat works.

[vsemozhetbyt]

It would be ~300 re-editions in the PR...

[refack]

Your call @vsemozhetbyt if you have the energy do it. I'll review it.
If you say not this PR I'll retract those comments.

[vsemozhetbyt]

I am in doubt if there is a minimum consensus for this. If there are 2-3 +1 and no strong -1, I can try to refactor with path.join().

[addaleax]

Like James and Benjamin, I’m fine with leaving this as-is. Leaving path.join() refactors for a later PR sounds good to me. (If there’s consensus they should happen.)

[gibfahn]

Yep, seems like a job for a separate PR.

[refack]

+0
personally I'd rather you define as vars then do this trick

constmsg_json=JSON.stringify(message);constid_json=JSON.stringify(this.messages_[id]);assert(message['result'],`${msg_json} (response to ${id_json})`);

[vsemozhetbyt]

I've created some new variables if this improved many places per file. But I also tried not to be too creative to not overload the diff.

[refack]

not a big fan of the trick... And otherwise you can't fit it in one line...

[gibfahn]

+1 to @refack's suggestion, I think it definitely improves the readability.

[refack]

same

[refack]

const s = this.messages_.map(m => m.id).join(', ');

[vsemozhetbyt]

The same: I would abstain from refactoring too deep: this will make reviewing and testing a lot more difficult.

[refack]

Then I say, leave it as is, comment with TODO

[gibfahn]

+1 to @refack's suggestion again. While you're here you might as well simplify, and it's a simple atomic change (so not too painful to review).

[refack]

If using map, no need for substring

[refack]

-1
IMHO doesn't improve readability.
Maybe:

constexpectedWhite=`${expected.slice(0,60)}\u0020${expected.slice(60,120)}\u0020${expected.slice(120,180)}\u0020${expected.slice(180,240)}\u0020${expected.slice(240,300)}${expected.slice(300,360)}`;

[vsemozhetbyt]

This may not be linted (indents).

[jasnell]

Definitely not a fan of multiline string literals. An array with a join might be an even better option.

constexpectedWrite=[expected.slice(0,60),expected.slice(60,120),expected.slice(120,180),expected.slice(180,240),expected.slice(240,300),expected.slice(300,360)].join(' \n')+'/n';

[refack]

same

[refack]

+-0
IMHO change the whole assembly to [].push(x).join(' ')

[refack]

path.join

[refack]

my progress marker

[refack]

That's a huge PR indeed

[vsemozhetbyt]

I've reverted changes in the test/parallel/test-buffer-alloc.js and resolved conflicts.

[vsemozhetbyt]

I don't know what to do. To divide this PR in small ones, I lack criterions (by files number? by tests topics? other?). And I understand that other collaborators may not have my 2 free days to review all the changes (diff is very slow in addition). Feel free to say to close, I shall not consider this as a waste of time, this was a useful experience in many respects for me)

[refack]

I don't know what to do. To divide this PR in small ones, I lack criterions (by files number? by tests topics? other?). And I understand that other collaborators may not have my 2 free days to review all the changes (diff is very slow in addition). Feel free to say to close, I shall not consider this as a waste of time, this was a useful experience in many respects for me)

IMHO Keep it. It's done, it's good. I'll go over it all.

[refack]

Removed requests to hoist stuff to common.js, agree that that's a different PR.

[vsemozhetbyt]

O my) Conflicts resolved. New CI: https://ci.nodejs.org/job/node-test-pull-request/7758/

[vsemozhetbyt]

Some new conflicts resolved. Hopefully, the last CI: https://ci.nodejs.org/job/node-test-pull-request/7891/

[vsemozhetbyt]

Landed in 8b76c3e

Sorry for all the conflicts it may cause...

[gibfahn]

@vsemozhetbyt do you have the patience to backport this to v6.x-staging? If yes please follow the guide and raise a backport PR, if no let me know or add the dont-land-on label.

[vsemozhetbyt]

@gibfahn I can try, but will anybody have the time to review?

[gibfahn]

@gibfahn I can try, but will anybody have the time to review?

If you raise the PR I promise to review 😁 . Feel free to assign it to me.

[vsemozhetbyt]

@gibfahn Hopefully backported: #13835