Is there a way to use SuiteScript modules locally ( outside of NetSuite ) for development purposes?

No

I thought so too. Thanks for confirming. I was hopeful though. In terms of scripts, I only wanted to play with front end UI either using Client Scripts or just HTML files to be inlined later on.

For local testing you could just stub the modules

When running react apps as a Suitelet, I've always built mock APIs to match what my RESTlet would eventually provide. If the current environment was 'Production', use the API that would make calls to the RESTlet. If not, use the mock api with local JSON data.

@CD Is there any docs/tutorial how to do that? @Mike Robbins That’s a good idea. In the past, I have used local dev server which would call the RESTlets during development. It is an extra hassle but you get live data from NetSuite.

I've always run into CORS issues if I try to call live RESTlets from a locally run web page.

that’s where the local dev server comes in, that’s another server running something like express which listens to calls from React app and makes calls to NetSuite RESTLets

Gotcha. Yeah, that makes sense. Here's the API folder from a react/suitelet that shows how I just return JSON data when running locally and calls RESTlets when running in production: https://github.com/datatek-software/netsuite-react-order-entry/tree/master/src/api

Thanks, I will check it out.

my mind is churning and maybe blown. you are using react to serve up SPA out of NS?

When you come from web dev background, you prefer this for your front end development.

u are using JS to serve a SPA? are you using suitelets to have an authenticated page? or are you using SPA connecting to restlets? just curious

We do something similar but use Angular (mostly) and have iterated and formalized the backend API to support VERY rapid development.

@redfishdev In the past, for each custom NetSuite page, I have created an individual SPA project. My project compiles the app into single

.html

file which is rendered by a SuiteLet. It communicates with NetSuite backend using SuiteTalk/RestLet. During dev, call to RestLet is achieved using a local backend dev server as making calls from front end would cause CORS error. I have a boiler plate repo (Vue3 app) for this which is shared above. Currently, I work on a much bigger SDF project with multiple custom pages and suitescripts. The project compiles all the react files into respective SuiteScript types. The drawback here is you have to deploy the files to NetSuite to see the changes. I am trying to find a common ground between these two.

@Bibek Shrestha very nice. do the client auth keys get pushed to the browser?const consumer = { public: process.env.TBA_CONSUMER_KEY, secret: process.env.TBA_CONSUMER_SECRET, }; const token = { public: process.env.TBA_TOKEN_KEY, secret: process.env.TBA_TOKEN_SECRET, };

these keys are only used during the development so production code doesn’t have it

this was my authentication question

we take a simpler approach - for UI, run with fake data locally for dev, real data for integration testing. Testing the backend is independent, using jest to call the restlet/suitlet with sample payloads and interrogate responses.

@redfishdev during dev, a second server (express) handles the calls to restlet. It uses TBA method for authentication using those keys. For production, there is no need for this server or extra authentication as the compiled file is rendered in NetSuite using suitelet.

a main benefit of using mock data locally is parallel development - one person can be working on the UI whllst another is building out the backend API.

We are doing something similar with Shawn, front end (react) is tested with mock data. Webpack or parcel is firing up a test server. We write controllers that either look at test data or make calls to back end SL. So the code is exactly the same as the one we ship. When both back and front are ready we monkey test the whole app.