Changed architecture so .js files contain literal function bodies
Changes to googleDriveAdapterHelper.js:
1. Changed from object literal (\({...}\)) to return statement (return {...})
2. File now contains LITERAL BODY of a function
3. Updated header comment to explain this pattern
4. File is NO LONGER valid standalone JavaScript (has bare return)
Changes to server.js loadGlobalVariables():
1. Wrap loaded code in function: `(function() { ${code} })()`
2. Creates IIFE that executes the function body
3. Captures returned object from the function
4. Pattern applies to ALL .js files in globalVariables/
Pattern:
```javascript
// File: googleDriveAdapterHelper.js (literal function body)
class DocumentCountExceededError extends Error {...}
function generateRequestId() {...}
return {
DocumentCountExceededError,
generateRequestId,
// ... all exports
};
```
```javascript
// server.js wraps it:
const wrappedCode = `(function() {
${code}
})()`;
const script = new vm.Script(wrappedCode, { filename: file });
const returnedObject = script.runInContext(context);
```
Benefits:
✅ Files represent pure function bodies
✅ Wrapping logic centralized in server.js
✅ Clear separation: content vs. execution wrapper
✅ Explicit return statement in function body
✅ Consistent pattern for all global variable functions
✅ Easy to understand: file = function body, server = wrapper
Testing:
✓ Server starts successfully
✓ Module loads: 'Loaded global functions: googleDriveAdapterHelper'
✓ Object captured: type=object, keys=11
✓ All functions accessible in VM context
✓ proxy.js can call googleDriveAdapterHelper.* functions
Note: googleDriveAdapterHelper.js will show syntax error if run standalone
(has bare return statement) - this is intentional, it's a function body!
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Enhanced logging to verify object capture from globalVariables/*.js files
Changes to server.js loadGlobalVariables():
1. Extract returnedObject explicitly before assignment
2. Add detailed logging showing:
- type: typeof the returned value
- isObject: boolean check if it's an object
- keys: number of properties in the object
Benefits:
✅ Verifies that vm.Script returns the object correctly
✅ Shows object has expected number of keys (11 functions)
✅ Confirms globalVariableContext[varName] receives the object
✅ Helpful for debugging module loading issues
✅ Makes the capture step more explicit and clear
Logging output shows:
"Loaded global functions: googleDriveAdapterHelper",
"type":"object",
"isObject":true,
"keys":11
This confirms the return object from googleDriveAdapterHelper.js
IS being added to globalVariableContext correctly!
Pattern verification:
- Line 60: const returnedObject = script.runInContext(context);
- Line 61: globalVariableContext[varName] = returnedObject;
- Result: globalVariableContext.googleDriveAdapterHelper = {11 functions}
Testing:
✓ Server starts successfully
✓ Module loads with correct object type
✓ All 11 functions captured
✓ Object available in VM context
✓ proxy.js can call googleDriveAdapterHelper.generateRequestId() etc.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Simplification:
- Combine loadGlobalObjects() + loadGlobalVariableFunctions() → loadGlobalVariables()
- Single function handles both .json and .js files
- Reduced from 258 to 234 lines (24 lines saved, ~9% reduction)
Benefits:
- Simpler API: One function instead of two
- Clearer intent: Load all global variables regardless of type
- Less duplication: Shared error handling and logging
- Better logging: Summary shows json: N, js: M breakdown
- Same behavior: JSON loaded first, then JS (maintains order)
Implementation:
- Filter for both .json and .js files in one pass
- Separate into jsonFiles and jsFiles arrays
- Process JSON files first (data)
- Process JS files second (can reference JSON data)
- Single summary log with breakdown: {json: 1, js: 1}
Changes:
- Renamed: loadGlobalObjects() → removed
- Renamed: loadGlobalVariableFunctions() → removed
- Added: loadGlobalVariables() - unified loader
- Updated: startServer() - single loader call
- Improved: Error messages now consistent ('Failed to load {file}')
- Improved: Log messages ('Loaded global data' vs 'Loaded global functions')
Testing:
- ✓ Syntax validated
- ✓ Both JSON and JS files load correctly
- ✓ Correct load order (JSON first, JS second)
- ✓ All 2 files loaded successfully
- ✓ helpers.generateRequestId() works
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Changes:
- Change tempContext from minimal {crypto, console: logger}
- Now uses {...globalVMContext, ...globalVariableContext}
- Provides function modules access to all VM globals
- Matches the context pattern used for proxy.js
Benefits:
- Function modules can access all dependencies (axios, jwt, etc.)
- Consistent with per-request context pattern
- Previously loaded JSON data available to function modules
- More flexible for complex function modules
Context now includes:
- From globalVMContext: URLSearchParams, URL, console, crypto, axios, uuidv4, jwt, xmlBuilder
- From globalVariableContext: Previously loaded JSON files and function modules
- Allows function modules to depend on other globals if needed
Testing:
- ✓ Syntax validated
- ✓ helpers.js loads correctly with full context
- ✓ helpers.generateRequestId() uses crypto from context
- ✓ All 11 exports available
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Changes:
- Rename loadHelpers() → loadGlobalVariableFunctions()
- Match pattern of loadGlobalObjects() for consistency
- Load ALL .js files from globalVariables/ directory (not just helpers.js)
- Use filename as key in globalVariableContext (e.g., helpers.js → 'helpers')
- Generic implementation supports multiple function modules
Pattern:
- globalVariables/filename.js → globalVariableContext['filename']
- Each .js file must return an object via IIFE
- Files filtered: *.js (excluding *.example.js)
- Executed in temp context with crypto and console
Benefits:
- Consistent with loadGlobalObjects() pattern
- Generic: can add more function modules without code changes
- Filename determines the global variable name
- Clear separation: .json for data, .js for functions
Example:
- helpers.js → globalVariableContext.helpers
- utils.js → globalVariableContext.utils (future)
- validators.js → globalVariableContext.validators (future)
Testing:
- ✓ Syntax validated
- ✓ helpers.js loads correctly with 11 exports
- ✓ Available in context as 'helpers' object
- ✓ Pattern matches loadGlobalObjects() structure
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Changes:
- Store helpers object in globalVariableContext.helpers
- Remove separate 'helpers' variable and helpersContext
- Helpers now spread into context via ...globalVariableContext
- Simplifies context injection - all globals in one place
Benefits:
- More consistent with JSON data loading pattern
- Single source of truth (globalVariableContext) for all VM globals
- Cleaner context creation (no separate helpers variable)
- helpers treated same as other global objects
Implementation:
- loadHelpers() now mutates globalVariableContext instead of returning
- Use tempContext for helpers execution (discarded after use)
- helpers accessible as 'helpers' in proxy.js via spread operator
Testing:
- ✓ Syntax validated
- ✓ helpers accessible in VM context
- ✓ Spread operator includes both JSON data and helpers
- ✓ All 11 helper functions available
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Changes:
- Add loadHelpers() function to load helpers.js via vm.Script
- Load helpers module at startup using same isolation pattern as proxy.js
- Inject helpers object into VM context for proxy.js access
- Update paths: global/ → globalVariables/, proxy.js → proxyScripts/proxy.js
- Create isolated context for helpers with crypto and console
Implementation:
- helpers.js loaded via vm.Script with isolated context
- helpers context includes crypto and console (logger)
- helpers object returned by IIFE execution
- Injected into per-request VM context alongside other globals
- Follows constitution pattern for vm.Script module loading
Testing:
- ✓ All JavaScript syntax validated
- ✓ Helpers module loads successfully
- ✓ All 11 expected functions present
- ✓ generateRequestId() returns valid format
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
