npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@suitegeezus/suitecloud-stacker

v25.2.131

Published

SuiteCloud Stacker

Readme

Contains helpers for SDF (Node CLI edition)

Features

  • Collection of pre-configured hooks (commands) to manage customer accounts
  • Collection of pre-configured hooks to manage the outer project
  • Pre-defined handlers that you can pick and choose from for a given "command"
  • Types for SDF commands
  • command line enhancements

How SDF works in this project

SDF by default has a certain structure that makes the following (annoying?) assumptions:

defaultProjectFolder is flexible

The IDE plugins force you to use src. You can if you want but this is more flexible. It defaults to 'src' The reason you would NOT want to use src is if you wanted to use the plugin to match what is in the account but what is in your repo is either or both of:

  • has extra stuff you don't want to put into the account by accident
  • want to keep it separate

Attempts to facilitate any activity in an account-based project to be only for that account

For example, if you try to file:upload or project:deploy code it will prompt you for the account with only choices relevant to that project.

Installation

Pre-requisites

Desktop pre-reqs

Should work same on Windows but i haven't tested it and i might have messed something up for windows so let me know if you have issues and you can help me fix them

  1. Install SuiteCloud globally using the latest release version see @suitegeezus/suitecloud-cli read the documentation for it, to see the additional command line switches.

  2. Optional: Install nodemon globally

npm install -g nodemon
  1. Optional: Install a nice terminal that you like to use.
    • Highly recommend enhancing the mac shell with iTerm AND Oh my Zsh!
  2. Optional: Create an environment variable for SUITECLOUD_DIFF_TOOL
#➜  set | grep 'DIFF'
export SUITECLOUD_DIFF_TOOL='/Applications/./IntelliJ\ IDEA.app/Contents/MacOS/idea'

NetSuite pre-requisites

You will need to have:

  • SuiteCloud installed in the account
  • Oauth 2.0 turned on
  • SuiteScript, etc enabled

Install on Mac / Linux / Windows

Run npm install

npm install @suitegeezus/suitecloud-stacker

Usage: Hello World Example

  • install as above
  • open a terminal to the root folder

Stackable / chaining structure for SDF command hooks

This means your sdf.config.js can specify or replace commands something like this:

const commands = {
    'file:import': stack('file:upload')
        .stack(
            accountManageAuth.promptForAccountChoice()
        ).stack(
            fileUpload.fixFileUploadPaths()
        ).stack(
            fileUpload.compileFilesPrompt()
        ).stack(
            fileUpload.testFilesPrompt()
        )
        .done(),
};

Stacking

At the heart of this is a "Stackable" structure for SDF. It is expected and encouraged that you have at least one suitecloud.config.js for a customer account rather than relying on the outer one.

Also, don't bother with the IDE plugins. not only do they have their own limitations but they are a black box so you can't do anything about it.

This has the following usage

working directory

sdf must be called from a directory that has a sdf.config.js file.

As such if you setup a project using native command and run it then it will work because that process will create a sdf.config.js.

It is recommended that you set your sdf.config.js file to be the following:

const safeCommands = require('@suitegeezus/suitecloud-stacker/safeCommands'); 

// create the commands that you want
const commands = {};

// pass them through the stacker
safeCommands.makeSafeExports(
        {
           defaultProjectFolder: 'src',
           commands: stackerCommands,
        },
        {debug: false, block: false, autoCreateProjectJson: false,},
        module
);

Errors

No account has been set up for this project. Run "suitecloud account:setup" to link your project with your account.

This is a native SDF error that means you do not have a project.json Do not remedy this by creating a project.json as this will be created for you. --> Remedy this by having an --authid flag on your command line like this: sdf file:import --paths "/SuiteScripts/myfile.js" --authid td12345:dist

if that authid exists and the folder dist exists then the file will be imported there. A project.json file will be quickly created and destroyed in the process

Relationships between project directories and accounts

In Netsuite we write code. We don't (usually) write code specifically for a sandbox, nor for production. We write code for the customer for a solution and it goes through a dev process that involves sandboxes and production. e.g. SB2 / Dev -> SB1/ UA2 -> Prod

This should also be true of objects.

We can use SDF for both code (suitescripts) and objects.

Regardless of how many sandboxen you have... Regardless of what weird branching strategies you might have... or don't have. When we write code or create objects it is hella convenient and powerful to have both under source control and to use merging strategies that support the work we are doing...

In all of the above you can be end-user or a partner

So we have one folder for an account.

If you have sandboxes then we probably have multiple branches, but it doesn't matter. A "master" branch is our statement that this code is production worthy and ready to be vetted.

But I don't want my customer to be a sub-folder in this project!

You don't have to. There is nothing stopping you in git from (in fact it supports) having a subfolder be for a different repository.

Further, the ability to pull from source control does not mean that you will be able to file:deploy to the customer account. You still need to have an authenticated token to do that. And that probably means you'll need to have login privileges to the customer's account (production, sandbox or whatever).