https://netsuiteprofessionals.com logo
Join SlackCommunities
Powered by
Hi gents, Do you compile your TypeScripts into 1 ...
# suitescript
p
Hi gents, Do you compile your TypeScripts into 1 SuiteScript file or mirror exact lib structure 1:1? Stumbled upon different approaches and wonder about Pros&Cons.
n
We mirror 1:1. Not sure the pros or cons of doing it this way though. I would be curious to see how well combining them would work.
👍 1
p
According to ChatGPT 😆: === Merging multiple TypeScript files into a single JavaScript file can offer several benefits: 1. Simplified Management: Managing one file instead of multiple can simplify the deployment process and reduce the complexity of your project structure. 2. Performance Improvement: Loading a single JavaScript file reduces the number of HTTP requests that a browser needs to make, which can improve the loading time and performance of your application. === I wonder if the Performance benefits are worth the effort.
n
Probably depends on the account i guess. And how many customizations you are running. Like i have a customer we just started working with that has 15 client scripts deployed on a transaction record. Which is insane because NetSuite only runs the first 10. They will definitely benefit from combining functionality, which is part of the reason we got brought on to the account.
I feel like all the cons would come around version control working with multiple developers. I could see it being easy to mess up something with everyone working on a single file.
p
You are OK as long as those 15 CS are not coming from locked Bundles 😄
💯 1
Actually, I don't see the risk with multiple devs working on the same file if proper git branching is followed. But maybe I just need to try it first to see the real deal.
n
"if proper git branching is followed." IF being the key word there 😆
p
Isn't it everywhere: 😄
s
for the record, that chatgpt answer is crap.
p
No surprise. Why do you think so?
s
Server-side SuiteScripts are not loaded by browser, so any arguments to that effect are meaningless. There may be some argument for this with client scripts, but that is due to bugs in NS's AMD loader.
Regarding simplified maintenance - if you have a script A, which uses libraries B and C as dependencies. If you bundle them together you have a potentially much larger script and it voids any caching/optimization that can happen on the NS server side of things (e.g. caching B and C)
In some cases, the dependency of a script may be many times larger than the script itself. Imagine a script which has 10 lines of code manipulating dates. However, that date manipulation is tricky and the dev uses something like momentjs for the date manipulation. Well, the momentjs lib is many times larger than that 10 lines of code using momentjs. By bundling the script into one it prevent NS from doing any optimization/caching of momentjs independently.
Imagine then that you have 3 similar scripts that all happen to be using moment - if bundled then that means loading momentJS 3x. So now you have a situation where the code we've written is maybe a few KB, and momentjs repeated is like 500KB
That said, I've heard NS say in the past that the size of these scripts, even libs, is trivial relative to what else is going on in the backend - specifically I've heard it's not helpful to 'minify' scripts
The last argument is around version control. Also known as "DLL Hell" for old schoolers. Bundling everything avoids DLL Hell but brings about the problem of potentially many different versions of a dependency being used
So if a dependent scripts needs to be a single source of truth/shared then you really don't want to bundle it up in order to guarantee there's only one copy.
A canonical example of this for NS projects are environment-specific values/constants or even functions. We gather together account-wide constants into a single file, then reference that file from any scripts that need the data.
This has a couple benefits for us : 1. single source of truth and 2. we can have functional consultants maintain this file
p
Thank you @Shawn Talbert for deep analysis. Much appreciated!
1000000 1
s
Sorry for the long winded reply there 🙂
20 Views
Open in Slack
PreviousNext
Powered by