NetSuite-Sync, NetSuite Upload, and other vsCode plugins broken by TBA

This is conjecture, not fact, on my part. It began with our NetSuite upgrade to 2021.2, which broke NetSuite-Sync. NetSuite-Sync is a Visual Studio Code plugin that makes it easy to upload JavaScript files to sandbox or production NetSuite with a couple of keystrokes. It only supports credentialed authentication.

After waiting a couple days, trying to upload to both our production and sandbox, and even swapping URLs to NetSuite SOAP API, nothing worked. I even tried a different plugin “Netsuite Upload.” Again, I used a credentialed based authentication. It failed too.

I had been notified that all SuiteTalk apps were going to require Token Based Authentication, and would no longer support credential-based authentication, but I never equated this to NetSuite-Sync or “NetSuite Upload.” However, this appears to be what broke them.

And now I’ll cut to the case. If you are using NetSuite-Sync… well… you’re sunk! npm uninstall netsuite-sync -g.

I installed “NetSuite Upload” from directly from within vsCode. It’s a plugin. Just find it by name and click install. It’s different from NetSuite-Sync in that it doesn’t use the Netsuite SOAP API, but instead uses it’s own custom Restlet. It also supports Token Based Authentication (TBA).

There is a link in the NetSuite Upload documenation to download the latest vscodeExtensionRestlet.js. If you are a developer, you’ll know how to upload that to the NetSuite file cabinet and create a Script File Definition, as well as a Deployment. Do that next.

Here are some notes about setting up the Token Based Authentication.

Setup >> Integreations >> Manage Integrations >> New

Setup >> Users/Roles >> Access Tokens >> New

Be sure to copy the output from both the Integration and the Access Token when you hit save in the previous two screens. You won’t ever see that info again. So paste it into Notepad and put it somewhere safe. Then use it to fill out your NetSuite upload settings. Your Realm is your account number. In this case, it is my sandbox account.

The last thing I’ll mention is that I have folders in my source code repository. I organize my scripts by type, like Event Scripts, Suitelets, Restlets, etc. I do not have similar folders in the NetSuite SuiteScripts directory. I upload all scripts to s single folder. When I was using NetSuite-Sync, it always uploaded to one and only one folder, no matter where the file was located on my local hard drive. So I wanted NetSuite Upload to work the same. To accomplish this, I modified the vscodeExtensionRestlet.js file as follows:

I make sure that no matter what folder on my hard drive a file originates from, it ends up in “SuiteScripts/[2nd level folder]/”. Be sure to modify all three functions, getFunc, postFunc and deleteFunc.

That’s the lowdown. From there you can open any JavaScript file in your source tree and hit [ctl+n] & [ctl+u] to unload it to NetSuite. If you right click the file in the left Nav, you’ll see you have options to download files, compare files between your local copy and Netsuite. NetSuite Upload is more robust than NetSuite-Sync. The only drawback is it is not so easy to swap between production and sandbox. I’ll save that for another blog post. Happy computing!

3 thoughts on “NetSuite-Sync, NetSuite Upload, and other vsCode plugins broken by TBA

  1. Steven says:

    Have you you tried using the SuiteCloud Developer Framework (SDF)? Oracle has an official VS Code plugin which can be found It doesn’t require you to make access tokens in NetSuite and it also allows you to quickly upload files while recreating your local folder structure in NetSuite. It also allows you to manage NetSuite related dependencies. Highly recommend it. 👍


    1. Thanks for the tip. At this point, I’m very happy with NetSuite upload. It has several great features, like code compare between local files and NetSuite. It supports both upload and download. The only drawback I’ve found is an inability to easily swap back and forth between uploading to production and sandbox. However, that certainly makes it much harder to do any development directly in production, which is probably a good thing.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s