Developers using TypeScript; could you share practical examples where you feel TypeScript obviously saved the day for you vs regular SuiteScript? I know the obvious strong typed benefits etc, but for people who like flexibility and embrace simplicity after 7+ years using native SuiteScript I’m having a hard type remembering a single instance were using TypeScript could give me a meaningful benefit. I’m genuinely asking for practical examples that I’m probably missing and this is not mean to judge anybodies choice.

I wanted to share my opinion. I am using regular SuiteScript and I haven't felt the need to use the TypeScript at all. Honestly, I don't see the benefits at all when the underlying script is going to be vanilla JS anyway. May be someone can change my mind by sharing the examples here. 👀

In my opinion, it makes absolutely no sense to use TypeScript for NetSuite. When NetSuite will be able to execute it, then I will immediately switch to TypeScript and the reason for that will be strict typing and I suspect that the new engine will have a number of advantages.

So the first 4 years of netsuite dev I did vanilla JS and never had any complaints. Started with a new company around 5 months ago and they strictly use TS. The biggest benefit I see is really just quality of life things. Autocomplete works better for example. You end up catching things that would error out before even uploading the script. Things like that.

@Nathan L When I use WebStorm with native SDF and proper JSDoc, my code completion works perfectly fine, pretty much the same as TypeScript IntelliSense when you use types annotation. Which specific things do you remember from the top of your head that TypeScript would catchup before you upload the script/code? Which things do you feel it makes easier?

I've tried it and and I enjoyed developing in TypeScript, but found it much more difficult to troubleshoot/debug code in production. I'm sure there are ways to improve that, but I didn't take the time to learn at the time.

@eblackey Thats a great point. As soon as someone touches the code in the account without updating the typescript file, it throws everything off. @alien4u So one that came up yesterday. There is a suitelet that we send a transaction number and formId in the parameters to render the pdf, attach it to the transaction, and display it to the user. the render.transaction() takes a entityId and formId parameter that has to be a number. Unlike some functions that will allow string or number. I didn't really think about that as I was writing and just pulled the id's from the parameter and tried to pass them into the render function. At compile though, TS said 'no'. because the params get sent over as strings in the url. Its kind of a simple example and an easy fix, but just one of those things that saved me an extra few minutes.

I'd recommend you 'google' this topic. There's nothing really 'special' about SuiteScript in this regard - it's just another platform with a standards-compliant JS runtime. So all the reasons so many devs adopt TS apply to 'SuiteScript' just as well

@Shawn Talbert The reason I’m asking is precisely because I googled the topic and after 7+ years of native SuiteScript coding in more than 100+ NetSuite instances I’m failing to see the advantage of TypeScript considering the added overhead complexity and the native nature of SuiteScript simplicity.

@alien4u The biggest areas I find TypeScript helpful are for managing data. Yes it's overhead upfront, but it saves me far more time for development and especially for long term maintenance. Not even specifically for NetSuite APIs, just general data: • Write query > run in console to an object > create type from the results. From there everything I do using that data knows what the values in the data should be and I don't need to remember individual values. • Writing or consume API it's very helpful. ◦ I can copy in example return values when I'm consuming them ◦ I can document what data I'm returning when writing an API for others

I'd love to discuss details but am too busy today 😕 For myself, after over a dozen years of NS development I'd never go back to plain JS after using TS for a few years now.

I'd say a specific practical example would be when refactoring or even making minor changes to a file. There have been many times when I need to change what data is being returned from a function / API. I update the type and then my IDE highlights everywhere I need to update the code

@bbahrman Thank you, the query results object with annotated types is a good example. Not sure I understand the copying of return values when consuming them. The documentation could be handled via JSDoc when properly maintained.

@alien4u What I mean by that is creating an interface for data I'm getting from an API. This is a sanitized version from a recent ecomm integration I did. Yes JSDoc will document it for humans, but this keeps track of it for me in the code and auto completes the individual values

export interface IOrder {
  id: string; //  order id ex: "292078",
  subtotal: number; // ex 319.0
  tax: number; // ex 0.0
  shipping: number; // ex 0.0
  discount: number; // ex 0.0
  payment_method: "card";
  payment_success: null // todo ask Jon if this is ever something
  created: string; // ex "2023-10-04T23:26:47.641127-04:00"
  status: "accepted"|"shipped";
  total: number; // ex 319.0
  destination: string; // ex "123 W Main St | Wichita, KS"
  has_return_request: boolean;
  clinic_id: string; // ex "3040"
  shipping_speed: "Standard"; // todo check other values
  po_number: string; //ex  ""
  shipping_address: {
    name: string;
    address_one: string;
    address_two?: string;
    city: string; // ex: "Wichita"
    state: string; // ex: "KS"
    postal_code: string; // ex: "67205"
  }
  billing_address?: {
    name: string;
    address_one: string;
    address_two?: string;
    city: string; // ex: "Wichita"
    state: string; // ex: "KS"
    postal_code: string; // ex: "67205"
  }
  phone_number: string; // ex: "3162625321"
  name: string; // clinic name
  license_number: string; // ex: "6462"
  email: string;
  tracking_data: { carrier: string; tracking_code: string; }[];
  items: ILineItem[]
}

@bbahrman I see, another good example. Thank you 🙏

comment around jsdoc - jsdoc is just comments, not code and as such can be easy to get out of sync with the actual code. When you have TS enforcing types there's no chance for things to get out of sync because the types are code. Having types represented in JSDOC is a crutch for JS to be a little bit like TS. The TS type system is far more powerful than JSDOC. For that reason we do NOT put type information in JSDOC - though it's still great for other documentation purposes.

Agreed with Shawn @alien4u - I'm happy to answer other questions or get you started. I used Typescript a bit back in 2017 time period but was on a big team and had enough trouble getting people to use an IDE and version control - Typescript was a liability due to the lack of process adherence to the bare basics. I looked at it a bit over the years but the process control remained a concern. I've been now writing exclusively TypeScript for 1.5 years and would never go back to JS. My code is faster to write, easier to maintain, and there's less to debug. I think there was a week of adjustment when I started, but apart from the basic script structure (import and export instead of the define block) you can just write JS code if you wanted. You get more out of it with full adoption of assigning types for any custom data, but it's not a huge pivot to start out.

I'm using TypeScript now, let see how it goes, I'm in the middle of creating a development/repo structure than can be easily used from VSCode and WebStorm while still use the native SDF plugins.

With NFT, NS records are instances of classes - so it's impossible to get a field name wrong when reading/writing. This is one area where TS is especially helpful, because native SuiteScript just takes

string

as the field names and does not throw an error if you provide the wrong field name. Hence, this allows bugs that may not be caught for quite some time,and definitely not until AFTER you've deployed. By having strong typing on the shape of all NS records you never deploy code with a typo in a field name because any mistake there is caught by the TS compiler.

@alien4u There's a few different options. What I usually do is just have a top level TypeScript folder which compiles into the SuiteScript directory. For NetSuite apps, we've also done the TypeScripts in the app folder with it compiling to a build folder.

We compile the TS to JS to be sibling files, mirroring the file cabinet hierarchy. We also deploy both the TS and JS for completeness. SDF makes that easy.

I want to get into automating unit tests and think that to do that, setting up a typed object for the field values makes sense. I do it for submit values

@bbahrman we write all our scripts using this https://www.npmjs.com/package/netsuite-fasttrack-toolkit-ss2

Gotcha, thanks @Shawn Talbert, that makes sense. I see you're Explore > RSM so that makes sense, I know you all have a custom layer on top of NS. (@Nathan L and I are both with Head in the Cloud which is part of why we got into TypeScript more fully)

Ah awesome - we should mention to @alien4u that the @hitc/netsuite-types is a must-have for using TS with SuiteScript 🙂

^^ Hence why Ben and I are a little biased towards TS

@Shawn Talbert I appreciate that. We've had a bunch of people across the community contributing for years. I recently got involved with one small change and was impressed by the speed at which I got feedback from others at different companies. It's a good community. Looks like you recently published yours via NP which is cool - I know you all have been using it internally for a while but didn't realize you were sharing it out

Ironically, it's been open source all along (12 years+? if you include the SS1 versions). However, the effort to keep it open source internally has become harder over time. It's pretty mature at this point but we might just simplify our lives and evolve it internally in the future.

It seems like NetSuite is taking some notice. There was discussion about more formal support for TypeScript as well as adding some record shape specific documentation / apis at SuiteWorld. Who knows if it will go anywhere but glad we've slowly been progressing from outdated JS days

Yes, I'd love it if SuiteScript 3.0 basically replaced NFT 🙂

Oh, sorry I saw the published date, but realize I need more coffee and that was just the most recent version 🤦

I will let you know guys once I try it for a while etc... I'm a big fan of vanilla JavaScript flexibility and SuiteScript simplicity, it would take some time for me to decide. I have very strong opinions about some topics, OOP for instance, for me is just an over engineered paradigm used by Silicon Valley to squish more money out of investors. In reality 70% if not more of projects out there do not need OOP complexity at all because the projects itself are not complex or big enough. But again, this is just my personal opinion...

One thing to consider is your dev team. If going with TS would make it harder to find a Netsuite developer to take over a project then I would rather stick to vanilla JS and enforce JSDocs and other good practices on code reviews which should be already be part of. I'd rather train the devs on good practices that can translate well to other languages. I was a consultant for years and rarely saw Suitescripts written in OOS and Typescript.

@borncorp I strongly believe that, I know more outstanding NetSuite Developers coming from Consultant roles and becoming Certified SuiteScript Developers without knowing a single line of TypeScript, than TypeScript Developers (seasoned full stack developers, excelling at NetSuite). That may be only my experience, but I don’t think so.

@alien4u Some devs like to overengineer things, I don't know if it's because they are paranoid or maybe for job security or perhaps they learned from someone who worked in environments where high collaboration is the norm like FAANG. 99% of companies don't need that much overhead. The 1% that does probably is looking to migrate to another ERP anyways because they are hitting other limitations with Netsuite.

Yes, better results maybe, the problem is you end up with a code monkey and not somebody who understands the business and can rezone and execute.

True, but engineering requires deep technical knowledge whereas the business can be learned through gradual exposure, an engineer gets there eventually. Moreover, in the ERP space rarely there's a developer who knows both sides and is working isolated from the business. Projects are done by teams. There's usually someone more functional that can understand the requirements and there's even multiple layers of business testing and requirement gathering. The business users are quick to tell if something doesn't work from a functional standpoint. An analogy would be like getting an interior designer to build a house vs getting an engineer to build a house. The engineer would focus on the structure, wiring, plumbing, etc.. is up to code, whereas the designer would focus on the living spaces, look and feel of the place. If I had to choose I'd rather hire the engineer to build the house to make sure that the place doesn't burn down, I can always tell the engineer if the rooms are too small or there are too many living rooms, that's something that's obvious to the person who will inhabit the house. The engineer would also learn from that and improve on the next house. On the other hand, if I were to choose the designer, I wouldn't be able to tell if the plumbing wasn't done properly until it's too late and I find out the toilets overflow if someone flushes while someone is taking a shower.