@suitegeezus/suitecloud-stacker 25.2.127

package/.idea/compiler.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="TypeScriptCompiler">
+    <option name="nodeInterpreterTextField" value="$USER_HOME$/.nvm/versions/node/v20.20.0/bin/node" />
+  </component>
+</project>

package/.idea/git_toolbox_blame.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="GitToolBoxBlameSettings">
+    <option name="version" value="2" />
+  </component>
+</project>

package/.idea/git_toolbox_prj.xml

@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="GitToolBoxProjectSettings">
+    <option name="commitMessageIssueKeyValidationOverride">
+      <BoolValueOverride>
+        <option name="enabled" value="true" />
+      </BoolValueOverride>
+    </option>
+    <option name="commitMessageValidationEnabledOverride">
+      <BoolValueOverride>
+        <option name="enabled" value="true" />
+      </BoolValueOverride>
+    </option>
+  </component>
+</project>

package/.idea/misc.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="ProjectRootManager" version="2" languageLevel="JDK_17" default="true" project-jdk-name="17" project-jdk-type="JavaSDK">
+    <output url="file://$PROJECT_DIR$/out" />
+  </component>
+</project>

package/.idea/modules.xml

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="ProjectModuleManager">
+    <modules>
+      <module fileurl="file://$PROJECT_DIR$/.idea/suitecloud-stacker.iml" filepath="$PROJECT_DIR$/.idea/suitecloud-stacker.iml" />
+    </modules>
+  </component>
+</project>

package/.idea/suitecloud-stacker.iml

@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<module type="JAVA_MODULE" version="4">
+  <component name="NewModuleRootManager" inherit-compiler-output="true">
+    <exclude-output />
+    <content url="file://$MODULE_DIR$" />
+    <orderEntry type="inheritedJdk" />
+    <orderEntry type="sourceFolder" forTests="false" />
+  </component>
+</module>

package/.idea/vcs.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="VcsDirectoryMappings">
+    <mapping directory="" vcs="Git" />
+  </component>
+</project>

package/CONTRIBUTING.md

@@ -0,0 +1,72 @@
+## the project type is 'commonjs'
+suitecloud-cli will only look for a config with a `.js` and never a `.cjs` extension!! 😓
+this conflicts with how suitescript unit tests are written which is with es6 modules.
+It is possible to use modules with flags on node so that is what we will need to do.
+This means certain files such as suitecloud.config.js may show some resolve errors. There are some other ways to get around this b
+
+## Your authentication is setup correctly and you are definitely pushing or pulling from the implied environment
+Unfortunately, we are human and make mistakes. But SDF doesn't care
+When authentication is set it will just assume this is what you want and has no safety net.
+
+this project solves this problem by:
+- Using the `@suitegeezus/suitecloud-cli` which has an authid argument available
+  - requiring the authid to be passed onto the command line
+- detecting it is set in the hooks
+- optional: erasing the project.json file before and after every execution.
+- prompting you to enter the same authid a second time during the action
+
+# Testing
+
+This project lacks unit tests. It was initially difficult to figure out how to test a cli such as suitecloud more effectively in a unit test than in on the command line itself especially because it did not publish its hook behaviour. So it was often better to test by running the commands locally.
+
+However, there should be unit tests and the stackable system makes it easy to do so. 
+
+Running the compiler with `map` files and in watch mode helps a lot. 
+
+# Writing Code
+All code needs to be in Typescript
+
+Anything that is a stackable handler should be for a specific command and be in the `commands/` directory. 
+
+e.g. something for `file:import` goes in  `commands/fileImport.ts`
+
+Each handler should be function that return `SdfCommand` type.  Which has this shape:
+```ts
+interface SdfCommand{
+    beforeExecuting?:  <O>(options:O)=>Promise<O>;
+    onCompleted?:  <O>(options:O)=>Promise<O>;
+    onError?:  <S>(err:S)=>Promise<S>;
+    projectFolder?: string;
+    /** @description - non native but added for detection */
+    stacked: true;
+    isStackable: true;
+    _origin: string;
+}
+```
+
+## Throwing Errors
+- SDF only passes strings to `onError`
+- SDF always prints the message
+
+- so ....
+You should call `makeError` when throwing errors. This will throw a serialized string but log the stack first. 
+```ts
+throw onErrorHelper.makeError(origin, new Error('whatever'));
+```
+
+Your `onError` method should be the returnType of `detectOriginAndReturn`
+
+```ts
+onError : async (error:string)=> onErrorHelper.detectOriginAndReturn(
+    origin, // : string,
+    error, // string--  the non-serialized message  
+    (e: string /* this will only be the message portion */)=>{
+      // you can do things in here like
+      // - print a friendlier message when it's not a catastropich error
+      // - print a usage
+    }
+  );
+```
+If you need the results of an SDF command that is supported and you'll see examples
+
+Anything that is re-usable should be somewhere in `sdf/lib`. 

package/README.md

@@ -0,0 +1,242 @@
+Contains helpers for SDF (Node CLI edition)
+
+# Features
+- Collection of pre-configured hooks (commands) to manage ACS problems withing customer account
+- 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
+
+Missing: Collection of hooks to manage an entire instance -- Cuz we (ACS) don't do this but if you have your own instance / demo account then feel free to create your own suitecloud.config file and use the stackable structure.  Note that most customers don't really do this either -- they often have outside devs who contribute at least sometimes
+
+# Demos
+
+## `account:setup:ci` : Token Auth Memory
+Setup token auth for an account from existing token auths that you have with detection for conflicts and valid naming
+![example](./img/accountsetupci.example1.gif)
+
+## `project:create`: New Account
+Create project to work on a case
+![example](./img/projectcreate.example1.gif)
+
+## `project:create`: New Case on Account
+![example](./img/projectcreate.example2.gif)
+
+## `file:upload`: Globbing that filters out irrelevant files
+![example](./img/fileupload.example1.gif)
+
+## `file:upload`: Upload all files from a deploy.xml file
+![example](./img/fileupload.example3.gif)
+
+## `file:upload`: Compile and / or run tests on files you are uploading
+![example](./img/fileupload.example4.gif)
+
+## `file:import`: Compare your current file with what is in the account
+![example](./img/fileimport.example3.gif)
+
+## `file:import`: Import files that match a glob pattern
+![example](./img/fileimport.example2.gif)
+
+## `file:import`: Import all files from a deploy.xml file
+```shell
+cd /SuiteScripts/ACS/casefolder
+suitecloud file:import --paths ./deploy/deploy.xml
+```
+
+## `object:import`: import objects that match a glob pattern
+![example](./img/objectimport.example1.gif)
+
+## `object:import`: import all objects that are listed in a chosen deploy.xml file
+![example](./img/objectimport.example2.gif)
+
+## `project:deploy`: Choose which project definition to deploy
+
+## `object:import`: Import Objects will organize them into folders by type automatically
+![example](./img/objectOrganization.png)
+
+## Compile and test typescript as you write
+![example](./img/nodemon.example1.gif);
+
+# 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
+
+One emample in this project is that to do diffs it will automatically create a root `temp` for you.
+
+## 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
+2. Optional: Install nodemon globally
+```shell 
+npm install -g nodemon
+```
+3. Install a nice terminal that you like to use. 
+   - Highly recommend enhancing the mac shell with iTerm AND [Oh my Zsh!](https://ohmyz.sh/)
+4. Optional: Be able to sync repositories with ALM via OCNA
+   - These are entitlements that will help you stay on the latest version of this repo and use customer repos
+   - If you can't then you can still use this for your testdrive accounts -- just ask me how
+5. Optional: define `oraclegit` in your ssh **config**  (highly recommended)
+```txt
+HOST oraclegit
+   User gerald.gillespie@fullscript.com
+   HostName alm.oraclecorp.com
+   TCPKeepAlive yes
+   AddKeysToAgent yes
+   UseKeyChain yes
+   IdentityFile ~/.ssh/ed25519ggoracle2
+```
+6. Optional: Create an environment variable for DIFF_TOOL
+```shell
+#➜  nsaccounts git:(main) ✗ set | grep 'DIFF'
+export 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
+1. clone the repo (not the weird extra slash `:/` ALM needs)
+```shell
+git clone oraclegit:/nscs_suitecloud-stacker_114170/suitecloud-stacker-root.git
+```
+2. Run npm install
+```shell
+npm install
+```
+
+# Usage: Hello World Example
+
+- install as above
+- open a terminal to the root folder
+
+
+
+## Pre-Defined Stacks for the Common scenario
+- Collection of hooks meant for ACP subprojects (e.g. a specific case/ project)
+```js
+const safeCommands = require('suitecloud-stacker/safeCommands.js');
+module.exports = {
+            ...projectJson,
+            commands: {...safeCommands.caseCommands},
+        },
+        {debug: false, block: false},
+        module
+    
+```
+
+### Spin up a new SDF project for a case 
+You can use this command to create your own case
+```bash
+cd ~/code/projectRoot
+suitecloud project:create
+# follow-the prompts
+```
+
+## Stackable / chaining structure for SDF command hooks
+This means your suitecloud.config.js can specify or replace commands something like this:
+
+```js
+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
+
+### `--authid`
+supports a format like this `2452352:wut` where the value before the `:` is the authid and the value after the colon is the folder name.
+
+if you only specify the first part without any colon then the same value is used for both. i.e. `2452352` is equivalent to `2452352:2452352`
+
+you can create this anywhere.  Wherever you create it you should invoke it from there. 
+e.g. 
+```bash
+cd FileCabinet/SuiteScripts/folder
+suitecloud 
+```
+
+## working directory
+native `suitecloud` must be called from a directory that has a `suitecloud.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 `suitecloud.config.js`. 
+
+It is recommended that you set your `suitecloud.config.js` file to be the following: 
+
+```js
+const sdfAcs = require('./sdf/safeCommands'); 
+
+// create the commands that you want
+const commands = {};
+
+// pass them through the sdfAcs layer
+module.exports = sdfAcs.makeSuiteCloudConfig({commands});
+```
+
+# 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 the customer has...
+Regardless of what weird branching strategies they might have... or don't have.
+Regardless of whether we are writing code for the customer's use or writing code the helps us create the solution for the customer...
+Regardless of how many cases are concurrently being worked on for a customer...
+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 for the customer. 
+
+In all of the above you can have a real "customer" or it could simply be a concept "customer" 
+
+So we have one folder for a customer. 
+
+If a customer has multiple sandboxes then we probably have multiple branches but it doesn't matter.  Our "master" branch is not the customer's master branch. It 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. That repository can have different users.  ESS member Bob can have a different set of accounts from Raffi and they can share any overlapping number of them.  But when they want to collaborate on something in source control related to an account they can `pull` from a common view and still work independantly on separate branches and yet have full visibility into the other work. 
+
+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). 

package/bin/updateModule.d.ts

@@ -0,0 +1,6 @@
+/**
+ * @file /Users/geraldgillespie/code/nsaccounts/sdf/bin/updateModule
+ * - keeps module up to date with what is in the current directory
+ * @author Gerald Gillespie <gerald.gillespie@fullscript.com>
+ */
+export {};

package/bin/updateModule.js

@@ -0,0 +1,12 @@
+"use strict";
+/**
+ * @file /Users/geraldgillespie/code/nsaccounts/sdf/bin/updateModule
+ * - keeps module up to date with what is in the current directory
+ * @author Gerald Gillespie <gerald.gillespie@fullscript.com>
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+const updateModule_1 = require("../lib/updateModule");
+(async () => {
+    await (0, updateModule_1.updateModuleTypeDef)();
+})();
+//# sourceMappingURL=updateModule.js.map

package/commands/CONTRIBUTING.md

@@ -0,0 +1,7 @@
+In this folder each library should export handlers related to an SDF command. 
+
+e.g. fileImport.ts serves `file:import` related commands.
+
+These handler should return sdf-expected methods and each method should be stackable / chainable.  See [sdf/safeCommands/stack](../safeCommands.ts);
+
+Tests would be great. Use proxies to glean the arguments that SDF passed in and use those as your mock options.

package/commands/accountManageauth.d.ts

@@ -0,0 +1,93 @@
+/**
+ * @file /Users/geraldgillespie/code/nsaccounts/sdf/commands/accountManageauth
+ * @author Gerald Gillespie <gerald.gillespie@fullscript.com>
+ */
+import { SdfCommand, StackableHook } from "index";
+type AccountManageAuthOnCompletedOptions<A = 'list' | 'remove' | 'rename' | 'info'> = {
+    _status: 'SUCCESS' | string;
+    _commandParameters: A extends 'list' ? {} : A extends 'info' ? {
+        info: string;
+    } : never;
+    _actionExecuted: A;
+    _data: {
+        authid: A extends 'info' ? string : undefined;
+        authId?: string;
+        accountInfo: {
+            companyId: string;
+            companyName: string;
+            roleId: string;
+            roleName: string;
+            entityId: string;
+        };
+        token?: A extends 'list' ? {
+            accessToken: string;
+            expirationDate: string;
+        } : never;
+        domain?: A extends 'info' ? string : never;
+        hostInfo?: A extends 'list' ? {
+            hostName: string;
+            clientId: string;
+        } : never;
+        certificateInfo?: A extends 'list' ? {
+            privateKeyPath: string;
+            certificateId: string;
+        } : never;
+    };
+};
+/**
+ * @description - save the list of account details as json
+ */
+export declare const saveList: () => SdfCommand;
+type BetterAccountList = {
+    authid: string;
+    authId?: string;
+    domain: string | null;
+    accountInfo: {
+        companyId: string;
+        companyName: string;
+        roleName: string;
+        entityId: string;
+    };
+    auth: {
+        certificateId: string;
+        privatekeyPath: string;
+        expiration: string;
+    };
+};
+/**
+ *  @description - Filters an account list for those relevant to the given account
+ *  @example ```js
+ *  authid: "ACMEINC-DEV",
+ *     domain: "654321-sb1.app.netsuite.com",
+ *     accountInfo: {
+ *         companyId:"654321_SB1",
+ *         companyName:"Acme, Inc (SB2)",
+ *         roleName: "Administrator",
+ *         entityId: "1324546",
+ *     };
+ *     auth: {
+ *         certificateId: "aEB5fUYumwJbnvP09kR",
+ *         privatekeyPath: "/Users/geraldgillespie/.keys/sdfgg.pem",
+ *         expiration: "2025-03-05T14:29.3961Z",
+ *     }
+ *  ```
+ * @returns {Promise<ReturnType<makeList>>}
+ */
+export declare const fetchAccountList: () => Promise<BetterAccountList[]>;
+export declare const betterList: () => SdfCommand;
+/**
+ * @description - Prompts for account choice. This provides both verification and literal choice. If the choice does not match the current
+ * context then an error is forced -- this is because SDF does not recognize a change in the account after launching.
+ * @returns {*}
+ */
+export declare const promptForAccountChoice: StackableHook<any, any, never, any>;
+/**
+ * @description -
+ * @param options
+ */
+export declare const validateList: (options: any) => {
+    _origin: string;
+    onCompleted: (options: AccountManageAuthOnCompletedOptions) => void;
+    isStackable: boolean;
+};
+export {};