Assume

• 3 <= num <= 3 * 10^6
• 1 <= opers length <= 2 * 10^4
• 1 <= opers[i][0] <= opers[i][1] < num
• 0 <= opers[i][2] <= 10^9

That would actually be

• 3 <= num <= < 3 * 10 ^ 6 5
• 1 0 <= opers[i][0] ..
• .. opers[i][2] <= < 10 ^ 9

Also, please be consistent in specifying upper ( and lower ) bounds as inclusive or exclusive. Because some numbers are used as indices, inclusive lower bounds and exclusive upper bounds generally make sense. ( Hence the random generator .. )

1 <= opers[i][0] <= opers[i][1] <= num

I think that's still from the 1-based version. ( Or you're excusing yourself for generating OOB indices. But you don't specify what to do in that case, keeping or extending the bounds. )

If this is to be a 4 kyu kata, testing is wholly inadequate.

Not an Issue because it might just not be a 4 kyu kata ..

Why 1-based indexing? This is JavaScript. JavaScript uses 0-based indexing.

( "I was lazy" is not a good answer. Nor is "I was feeling obstinate and just wanted to punish solvers for no good reason." )

Why Node v10 ? Why not Node v12 ?

Random tests generate ranges outside [1..n]