How people handle this limitation? you can reach that limit very easily: • Vertex alone uses 4 slots • RF-SMART uses 2 more slots. Considering only two bundles or SuiteApps.

Aren't client scripts required to be unlocked? Maybe you could consolidate them yourself?

Potentially yes, but crazy... That would make us responsable/liable for those script functionality that we are paying for, I would try to avoid that as much as I can.

In the past, we've consolidated our own client scripts down to essentially 1 per record. Creating a single client script that loads other existing client scripts as modules and then calling

function saveRecord(context) {
    return module1.saveRecord(context)
        && module2.saveRecord(context)
        && module3.saveRecord(context);
}

It's not ideal, but it lets us keep the logic separate while still reducing the number of scripts.

Thank you, I would probably use that, I like it, still a crazy limitation considering it could be overflowed by bundles very fast and very easily.

I use a similar approach as @Mike Robbins but instead of modules, I create functions and call them from the entry points.

function saveRecord(context) {
    return saveRecord1(context)
        && saveRecord2(context)
        && saveRecord3(context);
}

This is still a big problem at least for us: • We have 9 slots used by paid SuiteApps and/or Bundles. Meaning, another bundle could left us without an option to consolidate, I don't see how we should be responsable for consolidating paid SuiteApps or Bundles' Client Scripts, that is not sustainable, we will need to re-consolidate on each update of any of those bundles.

Then those Bundles should consider using only 1 client script. NetSuite should force the devs/partner to follow this.

it is in the SDN questionnaire... they specifically ask if you have consolidated your client scripts and you have to explain why you have not; I assume they are still getting approved

So NetSuite has a policy, partners are not following it and NetSuite is not forcing it. Just another day with NetSuite

It looks like they are not enforcing that enough, I have an RF-Smart Client Script that is just a confirm dialog if a field is populated on save. Literally 5 lines of code

no one's mentioned it yet but the limit on client scripts is lowkey 20 not 10... you get 10 on the record and another 10 on the form

What blows my mind is that the bigger offenders are super famous SuiteApps (company size kind of deal): • Vertex • RF-SMART • A Payment SuiteApp I don’t remember the name right now.

lol why would that blow your mind? that's exactly the groups that can ignore the rules and not be punished

That is the group I would expect quality, compliance and performance.

I might argue that team/company size has no correlation with quality

Looks like you haven't seen the code of some of NetSuite partners. Worst code ever!

I think that's a perfectly reasonable expectation but not what I've seen in the NS space

I agree 100% with you guys, I’m talking about expectations, but yes, I have seen plenty of “wonderful” code not only from partners but from NetSuite Professional Service or Suite Success Teams, crazy stuff… lol 😂

is that even a reasonable expectation? I feel like "quality" of a product will tend to the level of quality of the worse dev that touches it over time. small group or even single dev projects will have the quality of that dev, which is highly variable, but probably consistent or even improving over time. A larger corp with lots of turnover lots of busy devs, some of which are very junior, will generally get worse and worse code without some SERIOUS effort on the part of the dev management people to ensure quality, and that's just a hard problem to solve... I'm sure @erictgrubaugh can talk for days on this subject 😉

I have seen UserEvent scripts with more than 3k lines without a single function declaration aside from the entry points, mega gigantic IF statements.

@alien4u isn't that how it should be done? 😄

I personally follow some sort of methodology I learned from @erictgrubaugh , code reviews are not a joke and your product/team quality depends heavily on that.

It is difficult - I'm part of a team of 50 NS devs and we do spend a lot of time and effort driving (and complying) to quality standards.

For me these are key things in the Development Process for a Team (and again I learned most of this from @erictgrubaugh and @mattdahse): • Well defined UAC process. • Rigorous Code Reviews (hand to hand with well defined Coding Standards) • QA • UAT

IMHO it gets increasingly important as the organization grows in order to have everyone producing code that can be maintained easily by anyone else on the team.

the problem is, its really difficult to quantify the value of that effort, which makes advocating for it to higher ups that don't already know... challenging

True. One tangible measure is reduced write-offs, but quality and standards only contribute a portion to that. Certainly helps to have buy-in from the 'higher ups' from the get-go.

the value is there for sure, but its spread accross thigns like development velocity, employee retention, employee satisfaction, customer satisfaction, reduce rework, bug tickets that ARENT created

These are all from a NetSuite bundle netsuite

I got you 😉 , my problem is that after paying top dollars for NetSuite and the Bundles, we (the administrators, developers) should not be the ones maintaining this madness…