Merge branch 'main' into feat/package-branch-dependency

.github/FUNDING.yml

@@ -0,0 +1,3 @@
+# These are supported funding model platforms
+
+github: azlam-abdulsalam

.github/workflows/buildPackages.yml

@@ -40,8 +40,8 @@ jobs:
           git config --global user.name "ciuser"
 
 
-      - name: 'Bootstrap Lerna'
-        run: npx lerna bootstrap
+      - name: 'Install Dependencies'
+        run: npm i
 
 
       - name: 'Build  All  Packages'

.gitignore

@@ -20,4 +20,6 @@ packages/core/.sfpowerscripts/**
 
 coverage/**
 packages/apexlink/coverage
-packages/sfpowerscripts-cli/oclif.manifest.json
+packages/sfpowerscripts-cli/oclif.manifest.json
+packages/apexlink/tests/resources/core-crm/apexlink.json
+packages/apexlink/tests/resources/feature-mgmt/apexlink.json

.vscode/settings.json

@@ -14,5 +14,10 @@
     "files.associations": {
         "*.log": "vt100"
     },
-    "editor.tabSize": 2
+    "editor.tabSize": 2,
+    "conventionalCommits.scopes": [
+        "sfp-cli",
+        "core",
+        "sfpowerscripts"
+    ]
 }

README.md

@@ -13,7 +13,7 @@
 </p>
 
 
-A build system for package based development in Salesforce, delivered as a sfdx plugin that can be implemented in any CI/CD system of choice.Read more about the plugin and details here - https://docs.dxatscale.io
+A build system for package based development in Salesforce, delivered as a node cli that can be implemented in any CI/CD system of choice.Read more about the cli and details here - https://docs.dxatscale.io
 
 #### Features
 
@@ -28,7 +28,7 @@ A build system for package based development in Salesforce, delivered as a sfdx
 
 There are lot more features to explore. Read more at  https://docs.dxatscale.io
 
-The project is delivered as a <b>SFDX CLI Plugin</b> that can be deployed in any CI/CD system, The plugin is available in  [NPM](https://www.npmjs.com/package/@dxatscale/sfpowerscripts) or can be 
+The project is delivered as a <b>CLI</b> that can be deployed in any CI/CD system, The module is available in  [NPM](https://www.npmjs.com/package/@dxatscale/sfpowerscripts) or can be 
 used by using the [docker image](https://github.com/dxatscale/sfpowerscripts/pkgs/container/sfpowerscripts)
 
 
@@ -59,7 +59,7 @@ To build sfpowerscripts execute the following on the terminal:
 ```
 npm i -g lerna #Install Lerna Globally
 cd <sfpowerscrips directory> # Navigate to the checked out directory 
-lerna bootstrap
+npm i
 lerna run build
 ```
 
@@ -73,7 +73,7 @@ To debug and test plugin
 
 ```
  cd sfpowerscripts-cli
- sfdx plugins:link
+ npm link
 ```
 
 #### Maintainers

decision records/009-migrating from-plugin.md

@@ -0,0 +1,22 @@
+# Migration of sfpowerscripts from SFDX Plugin to Standalone CLI
+
+- Status: Accepted
+- Deciders: @azlam-abdulsalam @vuha-acn @zhebinliu  @rakr
+- Date: 06/06/2023
+
+## Context and Problem Statement
+
+sfpowerscripts has been continuously adding features over the last four years, leading to an increase in the number of library dependencies. As an SFDX plugin,
+this has created a bit of load on the sfdx cli startup times. However, the primary concern arises from Salesforce's decision to deprecate 'sfdx' cli in favor of 'sf', which entails a shift in input parameters and argument styles. This change necessitates sfpowerscripts to adapt quickly to these new patterns. In addition, issues have been noticed during plugin installation, particularly with libraries using node-gyp which is required for functionalites such as reconciling profiles
+
+The deprecation of 'sfdx' by Salesforce also means that all documentation and usage practices have to be updated anyways.
+
+## Decision
+
+To address these issues and provide more flexibility in development and maintenance, it has been decided to migrate sfpowerscripts from being an SFDX plugin to a standalone CLI. This transition will enable it to function independently of the Salesforce CLI and change its features at its own pace. Users will be able to install sfpowerscripts directly from npm or use a Docker image.
+
+## Consequences
+
+This change will require users to adjust to a new installation and usage process. Documentation will need to be updated to reflect these changes. However, this migration will provide greater control over sfpowerscripts' development, allow for better handling of library dependencies, and bypass issues related to node-gyp during plugin installation. It also eliminates the necessity to rapidly adapt to new input patterns and argument styles introduced by Salesforce's 'sf' CLI. 
+
+In the long term, the transition to a standalone CLI will provide a more robust and flexible tool for users, irrespective of changes to Salesforce's CLI offerings

decision records/010-ship-show-ask-model.md

@@ -0,0 +1,36 @@
+# Adoption of Ship / Show / Ask Model
+
+- Status: Accepted
+- Deciders: @azlam-abdulsalam, @vuha-acn, @zhebinliu
+- Date: 06/06/2023
+
+## Context and Problem Statement
+
+As the sfpowerscripts project evolves and the number of maintainers is not fixed, maintaining an efficient workflow for integrating changes becomes essential. Traditionally, we've been using pull request reviews as a gatekeeper for merging code into the mainline. However, this process often introduces delays and can be a bottleneck, especially for non-controversial changes like bug fixes and documentation updates.
+
+Martin Fowler suggests an alternative branching strategy, Ship / Show / Ask, which could provide a more flexible and efficient workflow [[source](https://martinfowler.com/articles/ship-show-ask.html)]. 
+
+This branching strategy categorizes changes into three types:
+
+- Ship: Changes are merged into the mainline without review. This is ideal for non-controversial changes, like bug fixes and documentation updates.
+- Show: Changes are opened for review via a pull request and then immediately merged into the mainline. This provides a space for feedback and discussion, but doesn't delay the introduction of the change.
+- Ask: Changes are opened for review via a pull request and are only merged after discussion. This is for changes where input and agreement from the team is desired.
+
+The Ship / Show / Ask strategy respects the principles of continuous integration and continuous delivery and encourages conversation about the code, helping to maintain a feedback culture.
+
+## Decision
+
+We propose to adopt the Ship / Show / Ask strategy for sfpowerscripts. This decision is based on the following considerations:
+
+- It provides a more flexible workflow that can adapt to the nature of the changes being introduced.
+- It supports the principles of continuous integration and continuous delivery.
+- It encourages a culture of feedback and discussion without tying it exclusively to the pull request review process.
+- It puts key maintainers in control of the lifecycle of their changes, allowing them to decide when their changes are ready to go live.
+
+## Consequences
+
+Adopting the Ship / Show / Ask model will have the following effects:
+
+- It will reduce delays in merging non-controversial changes.
+- It will encourage more communication within the team about changes, leading to better overall code quality.
+- It will require maintainers to take more responsibility for their changes, including deciding when they are ready to be merged and seeking feedback when needed.