The reason I’m asking is because we still primarily develop in SS1.0. We create our files based on feature rather than Script Type of Event Type. But that means a file includes a combination of code that may run client side or server side. We want to restrict code to the lowest common denominator.

But we are simultaneously developing a CI/CD workflow using SuiteCloud IDE, a CI/CD server with SuiteCloud CLI and Maven, etc. So it would be trivial to add in a transpile step into the build process before the CLI validation and deployment.

There is a project here to leverage TypeScript for a much improved SS 1.0 development pipeline: https://github.com/ExploreConsulting/netsuite-fasttrack-toolkit

If you can, I'd encourage trying to make use of SS 2.0 for any new scripts that don't share code with or depend on any older SS 1.0 scripts or libraries. The main benefit is that you will be able to migrate to SS 2.1+ much more easily in the future, gaining ES10 support in the process, but will also be able to make use of the new Map/Reduce script type, which is tremendously powerful for processing large amounts of records or data.

At the every least, consider 2.0 M/R scripts as an alternative to SS 1.0 scheduled scripts. Other script types will not be much different other than syntax.

and I think you’ve sold me on the benefit to move to SS2.0 I’ve been resistant, but I’m beginning to understand this benefit.

I’m REALLY loving the ideas around this Fasttrack Toolkit. This is dope.

And btw, we rarely use the SS dat formatting with our current enhancements so that is actually the least of our issues.

Functionally, 2.0 is just a custom RequireJS wrapper around SS 1.0 anyway. They use the same engine. Other than support for the new script type, Map/Reduce, I mostly think of it as a transitional/bridge API between 1.0 and 2.1 The move to 2.1 will grant many additional benefits, notably a new javascript engine and a much more modern version of JavaScript, so in that spirit I made the leap to 2.0 to put ourselves in the best position to make that move in the future.

Well I thought I had my day planned out. I guess I’m going to at least begin by re-writting the feature I’m currently working on into SS2.0

I found the API mapping guides in SuiteAnswers you mentioned. so I’m going through that now. My biggest fear is figuring our how to restructure the code to implement the feature. I’m less considered about identifying the right methods.