Parse

docs/customruleguide.md

@@ -103,7 +103,7 @@ export class CustomRuleExample implements IRuleDefinition {
 
     // Start traversing the flow from a specific starting element
     // In this example, we'll start from the first element
-    compiler.traverseFlow(flow, flow.elements[0].name, visitCallback);
+    compiler.traverseFlow(flow, flow.elements.name, visitCallback);
 
     // Return the result of the rule execution
     return new RuleResult(this, []); // Assume no violations found for simplicity
@@ -116,6 +116,6 @@ In this example:
 - We define a custom rule class CustomRuleExample with an execute method.
 - Inside the execute method, we initialize a new instance of the Compiler.
 - We define a callback function visitCallback that is executed on each visited element. In this example, we check if the element subtype is a screen and perform custom logic accordingly.
-- We call the traverseFlow method of the compiler to start traversing the flow from the first element (flow.elements[0].name) and provide the visitCallback function.
+- We call the traverseFlow method of the compiler to start traversing the flow from the first element (flow.elements.name) and provide the visitCallback function.
 - Inside the visitCallback function, we perform custom logic based on the visited elements.
 - Finally, we return the result of the rule execution.

package.json

@@ -1,6 +1,6 @@
 {
   "name": "lightning-flow-scanner-core",
-  "version": "3.11.0",
+  "version": "3.12.0",
   "main": "out/**",
   "types": "index.d.ts",
   "scripts": {
@@ -15,7 +15,6 @@
     "@types/chai": "^4.2.21",
     "@types/mocha": "^9.0.0",
     "@types/node": "^20.4.5",
-    "@types/path-browserify": "^1",
     "chai": "^4.3.4",
     "logging": "^3.3.0",
     "mocha": "^9.1.1",
@@ -25,6 +24,8 @@
   },
   "packageManager": "yarn@4.1.1",
   "dependencies": {
-    "path-browserify": "^1.0.1"
+    "@types/path-browserify": "^1.0.2",
+    "path-browserify": "^1.0.1",
+    "xmlbuilder2": "^3.1.1"
   }
 }

readme.md

@@ -1,8 +1,9 @@
-# Lightning Flow Scanner
+ [![Lightning Flow Scanner Banner](./src/media/bannerslim.png)](https://github.com/Lightning-Flow-Scanner)
 
-_An Extensible Rule Engine for Salesforce Flows used by the Lightning Flow Scanner [Salesforce CLI Plugin](https://www.npmjs.com/package/lightning-flow-scanner) and [VS Code Extension](https://marketplace.visualstudio.com/items?itemName=ForceConfigControl.lightningflowscanner&ssr=false#review-details)._ 
+_An Extensible Rule Engine capable of conducting static analysis on the metadata associated with Salesforce Lightning Flows, Process Builders, and Workflows. Used by the Lightning Flow Scanner [Salesforce CLI Plugin](https://www.npmjs.com/package/lightning-flow-scanner) and [VS Code Extension](https://marketplace.visualstudio.com/items?itemName=ForceConfigControl.lightningflowscanner&ssr=false#review-details)._ 
 
 - [Default Rules](#default-rules)
+- [Core Functions](#core-functions)
 - [Configurations](#configurations)
   - [Rule Configuration](#rule-configuration)
   - [Custom Rule Interface](#custom-rule-interface)
@@ -29,6 +30,26 @@ _An Extensible Rule Engine for Salesforce Flows used by the Lightning Flow Scann
 | **Unconnected Element** ([`UnconnectedElement`](https://github.com/Lightning-Flow-Scanner/lightning-flow-scanner-core/tree/master/src/main/rules/UnconnectedElement.ts)) | Unconnected elements which are not being used by the Flow should be avoided to keep Flows efficient and maintainable. |
 | **Unused Variable** ([`UnusedVariable`](https://github.com/Lightning-Flow-Scanner/lightning-flow-scanner-core/tree/master/src/main/rules/UnusedVariable.ts)) | To maintain the efficiency and manageability of your Flow, it's advisable to avoid including unconnected variables that are not in use. |
 
+## Core Functions
+
+The `index.ts` file in this repository contains the core functionality of the Lightning Flow Scanner Core. Below is an overview of the main functions exported from this file:
+
+### `getRules(ruleNames?: string[]): IRuleDefinition[]`
+
+This function retrieves the rule definitions used by the Lightning Flow Scanner. It takes an optional array of rule names as an argument and returns an array of `IRuleDefinition` objects representing the rules to be executed.
+
+### `parse(selectedUris: any): Promise<ParsedFlow[]>`
+
+The `parse` function parses the metadata of Salesforce Lightning Flows, Process Builders, and Workflows from the provided URIs. It returns a Promise that resolves to an array of `ParsedFlow` objects containing the parsed metadata.
+
+### `scan(parsedFlows: ParsedFlow[], ruleOptions?: IRulesConfig): ScanResult[]`
+
+The `scan` function conducts static analysis on the parsed metadata of Lightning Flows, Process Builders, and Workflows using the specified rules. It takes an array of `ParsedFlow` objects and an optional `IRulesConfig` object as arguments and returns an array of `ScanResult` objects representing the results of the analysis.
+
+### `fix(results: ScanResult[]): ScanResult[]`
+
+The `fix` function attempts to automatically fix certain issues identified during the static analysis. It takes an array of `ScanResult` objects as input and returns a modified array with any applicable fixes applied.
+
 ## Configurations
 
 ### Rule Configuration
@@ -104,21 +125,21 @@ Follow these steps to set up your development environment:
 
     ```bash
     cd lightning-flow-scanner-core
-    yarn install
+    npm install
     ```
 
 3. **Build**: Compile the TypeScript source files into JavaScript using the TypeScript compiler:
 
     ```bash
-    yarn build
+    npm run build
     ```
 
     This command generates the compiled JavaScript files in the `out` directory.
 
 4. **Run Tests**: Ensure the module functions correctly by running the test suites:
 
     ```bash
-    yarn test
+    npm run test
     ```
 
     This command uses Mocha to run tests located in the `tests` directory and provides feedback on the module's functionality.