Hello awesome SuiteCloud community! This is Albert from the NetSuite Platform product team. As some of you already know, the new NetSuite Dev Tools product team is working in a CLI 2.0 experience for SuiteCloud developers so you can do more with less effort and work with any IDE that you want while still having a powerful CLI that lets you interact with NetSuite easily. I would like to show you our first prototype and get your feedback (good or bad!) and ask you whether you see yourself using it. The new CLI will be based in NodeJS and it's planned to be interactive so you don't need to read documentation or remember by heart all the params to get it working. We would appreciate A LOT your feedback! Thank you 🙂

Interactive is great, as long as it's not required. That is, a cli tool should (imho) always be able to be fully automated, and I hope all features will work in an unattended manner

Sure! We will provide options to use interactive or not interactive. We are not retiring the sdfcli, both options will coexist with the same level of functionality

oh, I was hoping the node based tool would be able to replace

sdfcli

functionality entirely. It would be a bit sad to have two separate commandline tools.

That's a good point. Our strategy at the moment is to keep both, however, that does not imply Node will always be interactive. I think Node should also have the ability to run in non-interactive mode. We want to keep both for the time being because: - There are integrations already built based on the java/maven-based CLI. For instance, IDE plugins, Continuous Integration pipelines, etc. We need to continue supporting them for a while and start a migration plan if we want to get rid of java - We believe that a java-based CLI has value for system-to-system integrations that are not based in JS

The beauty of a commandline tool is it's universal - a CI pipeline or any other command line client consumer should be able to invoke a node CLI just as it does a CLI written in Java or C.

Well, if you have NodeJS installed yes 🙂

my point is a commandline interface implies a text based input, text based output contract between the user and the tool.... which reveals nothing about the underlying implementation, be in Java, Nodejs, or small rodents on a treadmill

Understood and agreed

Aye, if you want cross-platform you need a cross-platform runtime for your cli.. - indeed Java and Node are probably the two most popular

Today we support a Java-based CLI that requires all consumers to install Java (and also maven, but that's another story). We want to move to Node but we should continue supporting those that set up their processes with the Java-based one or start the transition period (notification to customers, SLA changes, etc) to discontinue Java

Yes, totally agree about supporting existing customers!

We are improving the Java setup process for 19.1 (no more Maven!). And hopefully releasing the npm sdf 😄

both those sound great! The dependency on Maven I presume was more a convenience to make a CLI tool quickly, reusing other assets you already have implemented in Java?

That's still unclear. I think we want to focus on interactive CLI first but I think it will not be difficult to make it non-interactive. The hard part is making it interactive

It would be nice if even the java sdfcli was distributed via npm or some other package manager/service that allowed easy install and updates by end users.