@suitegeezus/suitecloud-stacker 25.2.129 → 25.2.130

package/README.md

@@ -17,8 +17,6 @@ The reason you would NOT want to use `src` is if you wanted to use the plugin to
 - 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. 
 
@@ -30,16 +28,16 @@ For example, if you try to `file:upload` or `project:deploy` code it will prompt
 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`](https://www.npmjs.com/package/@suitegeezus/suitecloud-cli)
+read the documentation for it, to see the additional command line switches. 
+
 2. Optional: Install nodemon globally
 ```shell 
 npm install -g nodemon
 ```
-3. Install a nice terminal that you like to use. 
+3. Optional: 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
-5Optional: Create an environment variable for SUITECLOUD_DIFF_TOOL
+4. Optional: Create an environment variable for SUITECLOUD_DIFF_TOOL
 ```shell
 #➜  set | grep 'DIFF'
 export SUITECLOUD_DIFF_TOOL='/Applications/./IntelliJ\ IDEA.app/Contents/MacOS/idea'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@suitegeezus/suitecloud-stacker",
-  "version": "25.2.129",
+  "version": "25.2.130",
   "description": "SuiteCloud Stacker",
   "main": "safeCommands.js",
   "scripts": {

package/CONTRIBUTING.md

@@ -1,72 +0,0 @@
-## 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/commands/CONTRIBUTING.md

@@ -1,7 +0,0 @@
-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/demo.md

@@ -1,26 +0,0 @@
-# Overview / Features
-
-* build a UserEvent that will help with adhoc debugging
-* 3 different UEs
-  * separation of beforeLoad, beforeSubmit, afterSubmit
-  * deployable to any record
-  * easier ordering of rank
-  * each can launch other UEs
-
-# Requirements
-
-
-# Objects & Scripts
-
-## Objects 
-1. UserEvent record for each entry point method
-   2. script parameter that will accept a scriptid / filepath (string) 
-
-## Scripts 
-1. Script for beforeLoad
-2. Script for beforeSubmit
-3. Script for afterSubmit
-4. A generic function to proxy an unknown script
-
-
-