JK, I figured this out, you need to load the script... we'll see if this is worth that governance

let allParameterIds = [];
let thisScript = record.load({
    type: record.Type.SUITELET,
    id: [YOUR SCRIPT ID]
});
let parameterCount = thisScript.getLineCount({
    sublistId: 'parameters'
});
for (i = 0; i < parameterCount; i++) { 
    let currentParameterId = thisScript.getSublistValue({
        sublistId: 'parameters',
        fieldId: 'internalid',
        line: i
    });
    allParameterIds.push(currentParameterId);
}

Curious what the goal is?

Also curious, normally parameters IDs do not change, so once you define them you can create your Object in your code with the parameters you want/need, if you are trying to do this because you have many parameters maybe parameters are not the right thing to use for this and you should consider a custom record.

I thought I was being clever by using this to create an object like let settings = { custscript_id_of_param1 = "foo", custscript_id_of_param2 = "bar", etc... } Then if I added parameters, I wouldn't need to update that bit of code. But as pointed out... to retrieve "foo", I'd still need to know the parameter id to get settings.custscript_id_of_param1. Additionally, VSCode won't prepopulate anything if i type "settings." if I go this route. Ultimately: I'm not actually going to do this. Thank you for critically criticizing. It likely saved me a headache later on

I try to resist being clever until I have no choice 🙂

I do something similar (translate params into Objects) very often, but it looks more like this:

function readParameters() {
        let script = runtime.getCurrentScript();
        return {
            errorAuthor: script.getParameter({name: "custscript_sma_errauthor"}),
            errorRecipient: script.getParameter({name: "custscript_sma_errrecipient"}),
            programSearch: script.getParameter({name: "custscript_sma_programsearch"})
        };
    }

I use a function that follows this pattern, but it's not intended to be reusable.

This is exactly how I have things set up now. I'll just continue to use this. Thanks for sharing

with TS you can ensure those settings are not accidentally assigned (the returned object is const) by adding

as const

to the end of that return statement object

I could also just

Object.freeze

it

aye, but that's runtime overhead and runtime check

Personally I don't, but I'm sure plenty around here do so it is useful for them 🙂

if I'm the Eric you're referring too.. I do not use TS, but I've dabbled in it and see the advantage

I do try to keep as much

const

as I can (e.g. I tend to use const over var/let - doing so means any time I actually see a

let

I know that variable is special and is getting mutated somewhere)

I'm good with VSCode's JS intellisense, the extension I made adds SuiteScript intellisense. So you can type "record." and the drop down shows "record.load", "record.attach" etc... The link gives a lot more info. https://marketplace.visualstudio.com/items?itemName=ericbirdsall.SuiteSnippets

aye, I'm in the 'never look back' camp myself.

Sing it @stalbert, I've been a TS guy for over 3 years now. I'll never to back. Combined with WebStorm and OOP, it's next level coding