@suitegeezus/suitecloud-stacker 25.2.129-5 → 25.2.129

package/README.md

@@ -1,62 +1,12 @@
 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 (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
 
-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: 
@@ -89,20 +39,10 @@ npm install -g nodemon
 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
+5Optional: Create an environment variable for SUITECLOUD_DIFF_TOOL
 ```shell
-#➜  nsaccounts git:(main) ✗ set | grep 'DIFF'
-export DIFF_TOOL='/Applications/./IntelliJ\ IDEA.app/Contents/MacOS/idea'
+#➜  set | grep 'DIFF'
+export SUITECLOUD_DIFF_TOOL='/Applications/./IntelliJ\ IDEA.app/Contents/MacOS/idea'
 ```
 
 ### NetSuite pre-requisites
@@ -112,13 +52,10 @@ You will need to have:
 - 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
+
+Run npm install
 ```shell
-npm install
+npm install @suitegeezus/suitecloud-stacker
 ```
 
 # Usage: Hello World Example
@@ -128,29 +65,8 @@ npm install
 
 
 
-## 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:
+This means your sdf.config.js can specify or replace commands something like this:
 
 ```js
 const commands = {
@@ -175,33 +91,29 @@ Also, don't bother with the IDE plugins. not only do they have their own limitat
 
 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. 
+`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 `suitecloud.config.js`. 
+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 `suitecloud.config.js` file to be the following: 
+It is recommended that you set your `sdf.config.js` file to be the following: 
 
 ```js
-const sdfAcs = require('./sdf/safeCommands'); 
+const safeCommands = require('@suitegeezus/suitecloud-stacker/safeCommands'); 
 
 // create the commands that you want
 const commands = {};
 
-// pass them through the sdfAcs layer
-module.exports = sdfAcs.makeSuiteCloudConfig({commands});
+// pass them through the stacker
+safeCommands.makeSafeExports(
+        {
+           defaultProjectFolder: 'src',
+           commands: stackerCommands,
+        },
+        {debug: false, block: false, autoCreateProjectJson: false,},
+        module
+);
 ```
 
 # Errors 
@@ -223,20 +135,18 @@ 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. 
+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 have a real "customer" or it could simply be a concept "customer" 
+In all of the above you can be end-user or a partner
 
-So we have one folder for a customer. 
+So we have one folder for an account. 
 
-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.  
+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. 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. 
+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). 

package/package.json

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

package/templates/customizations.projectroot.d.ts

@@ -4,7 +4,7 @@
 /**
  * @file {1}
  * - only use this once per account
- * - this is auto-generated file based on a search of the account.  See ESS query runner
+ * - this is auto-generated file based on a search of the account.
  * @author Gerald Gillespie <gerald.gillespie@fullscript.com>
  */