its likely they already made that change when doin...
# sdf
b
its likely they already made that change when doing the node cli
b
challenge accepted 🙂
m
WOMP WOMP:
b
ugh
m
it sure seems like the node cli is essentially just a wrapper for the same cli jar. i’m sure there’s some changes in the jar but meh.
b
it is
it execs a child process to run it
b
Ya, just a wrapper. I was hoping it might massage the output a bit more.
b
i was going for the 2020.1 java cli would need to be updated to work nicely with the node cli
a lot of the commands are a pain to work with programatically
m
i’ll take consistency in parameter names/short forms. 😄
to be fair though, the node version knows it’s an error, it’s applying formatting, so a bit of hacking could potentially get that state knowledge all the way out to the exit code
b
🤔 I might have to look into that...
I dunno, the right way to fix it would be in the jar itself though. I don't want to just muck with the UI.
b
node version doesnt know its an error, it knows there is output on standard error
i guess to be fair to the cli, that is a way to tell there is an error
and you can do the same logic
b
wait, is the jar output stderr or is it the node cli?
b
the java jar outputs to stderr
the node cli also outputs to sdrerr
b
hmm, ok, I think I should be able to work with that...
nice catch there
b
i expect that the 2020.1 jar has different process behavior because the code they use for executing commands doesnt really work otherwise
m
interestingly, the CLI doesn’t interact with the stderr at all unless the exit code is != 0, it’s just using chalk to modify the shell coloration. (the messages are still on stderr though) from SDKExecutor.js:
b
as i said, i expect different process behavior
m
this code is using the (at least nominally) 2019.2.1 jar still. (though, not necessarily the one we are using. which may be your point i guess) in any case, thus far it doesn’t seem like there’s anything to inform us about error states other than output to stderr for the forseeable future.
b
So, my solution for now is to verify that the error.log file does not exist or have content for my purposes... https://gitlab.com/tolaeon/sdf-starter/-/blob/develop/.gitlab-ci.yml#L43
I forgot that thing gets generated...
c
FWIW, when the VS Code plugin was built, I debated how frequently NetSuite would update the sdfcli output. As of today, it hasn’t changed output in two or so years.
a
We don't use stderr. There's a defined contract between JAR and Java only for the CLI so the Node.js CLI knows when the JAR is outputing errors and its messages. We can display errors in different ways in Node.js. Most likely will start using tables in the future 😉 I'd recommend to give a try to the 20.1 version as soon as it's available in npm. Your feedback will be welcomed to drive future improvements
👍 1
🙏 2