This code goes into an infinite loop as i always equals 0... what could be happening here?

Is this loop nested in another for loop using 'i' as a counter?

ah shit

yea and i would also like to see it supported for client scripts ;)

I'd strongly recommend just avoiding writing loops, for reasons like this.

@stalbert I need to make sure what is left behind here can be worked on by any NS contractor without them complaining about 'non-standard' use of SuiteScript

I understand, but respectfully disagree. IMHO not using libraries is a disservice to the customer and results in an inferior result and more time. The error you encountered would not have happened if you were using something like lodash. TypeScript isn't really relevant, except that it's another way to improve your code quality for customers.

We'll have to agree to disagree on that one then. I've had this same conversation with lots of people and it's a mixed bag of answers / opinions. I firmly believe that any SS person should be able to pick up a script without having to figure out a third party library that may or may not be flavour of the month.

let's just say the third party library is assuredly better documented than the alternative. It's a lot easier to understand a documented library than to reverse engineer hundreds of lines of code attempting to do the same thing.

I agree 100%

your very last statement above is exactly why I encourage use of third party libs. I feel far more confident in code utilizing something like lodash because it means LESS custom code written. I really don't want 'pseudo-devs' (or real pros for that matter) recreating any functionality that already exists in something like lodash. I'd suggest that lodash is even MORE important for casual developers than 'pros'. Using a library enables casual developers to benefit from professional code, rather than writing amateur code to do the same thing themselves, no?

You're not wrong. You're espousing the principle of reuse. Why do something from scratch if you can use a well tested and well documented library?

I recall once debugging an obscure bug in a large (500k lines) project. Turns out it was some 'clever' developer on the team that created their own String class. It was faulty. If they'd went with the standard string class they would have been better off. Nearly cost them a $1 million bonus.

Until you get a dev that lands on a project - sees your scripts using a library he doesn't understand / doesn't have enough billable hours to learn, complains to the customer that the previous dev used something "non-standard", then rips it all out and replaces with some SS1 spaghetti while the customer curses having worked with the previous dev.

Aye, I strive to write less code, not more, since each line I write is another potential bug 🙂

Well - if you're implementing your own string class then you're really doing it wrong. I'd say a 500k suitescript codebase with a custom string impl is really rare though

That was a large C++ program.

I came from Java land, very much in favour of strong libraries. I rarely built anything without third party libraries e.g spring, apache stringUtils etc

those principles are just as valuable in SuiteScript!