Initialize extensionRuntimeOptions in Runtime constructor to prevent TypeError

[coderabbitai]

Problem

Extensions attempting to access runtime.extensionRuntimeOptions encounter a TypeError because this property is not initialized in the Runtime constructor.

Requested Solution

Add proper initialization in the Runtime class constructor:

// In src/engine/runtime.js constructor
this.extensionRuntimeOptions = {};

Requirements

• ONLY modify the Runtime constructor - do not delete or modify any other code
• Add the single line initialization
• Add tests to verify the property exists and is accessible
• Add JSDoc documentation for the property
• DO NOT delete any files
• DO NOT remove any existing functionality
• DO NOT modify files other than runtime.js and test files

Success Criteria

• Property extensionRuntimeOptions is initialized as empty object
• Extensions can safely access the property without TypeError
• All existing tests continue to pass
• New tests verify the initialization
• Total changes should be ~10-20 lines added across runtime.js and test files

Related

• Replaces JS extension: initialize runtime.extensionRuntimeOptions and guard unsandbox flag to prevent TypeError #16 (which made unintended destructive changes)
• Backlink: JS extension: initialize runtime.extensionRuntimeOptions and guard unsandbox flag to prevent TypeError #16
• Requested by: @supervoidcoder

⚠️ Important Warning for AI Agents

This is a 2-line fix in the constructor. If your solution involves:

• Deleting hundreds or thousands of lines
• Removing entire files
• Modifying core VM functionality beyond the constructor
• Making changes to virtual-machine.js

STOP IMMEDIATELY and reconsider your approach. You are probably going down the wrong path.

[traycerai]

Plan

Observations

The issue is clear: extensions attempting to access runtime.extensionRuntimeOptions encounter a TypeError because this property is not initialized in the Runtime constructor. I found the actual usage in src/extensions/sp_javascriptV2/index.js at line 458, where it accesses this.runtime.extensionRuntimeOptions.javascriptUnsandboxed. The Runtime constructor follows a consistent pattern of initializing properties with JSDoc documentation. The test files use the tap framework and follow clear patterns for verifying property initialization.

Approach

Add the extensionRuntimeOptions property initialization in the Runtime constructor following the existing code patterns. Place it logically near other options objects like runtimeOptions and compilerOptions (around line 469). Add JSDoc documentation following the established format. Create tests in the existing test file to verify the property exists, is an object, and is accessible without errors.

Reasoning

I explored the repository structure, read the Runtime constructor section to understand the initialization patterns, examined the test files to understand testing conventions, and searched for existing usage of extensionRuntimeOptions to confirm the expected behavior.

Proposed File Changes

📄 src/engine/runtime.js ^(MODIFY) 🔗

Add the extensionRuntimeOptions property initialization in the Runtime constructor. Insert this after the compilerOptions initialization (around line 469, before the debug property). Follow the existing JSDoc pattern used for other properties in the constructor.

JSDoc to add:
Document the property as an object that holds runtime options for extensions, explaining that extensions can access this to check for specific runtime configuration flags.

Initialization to add:
Initialize this.extensionRuntimeOptions as an empty object {}.

Placement:
Insert between the compilerOptions initialization (line 465-468) and the debug property (line 470). This logical grouping keeps all options-related properties together.

The pattern matches other property initializations in the constructor, such as runtimeOptions at lines 459-463 and compilerOptions at lines 465-468.

📄 test/unit/engine_runtime.js ^(MODIFY) 🔗

References

• 📄 src/engine/runtime.js ^(MODIFY)

Add a new test case to verify the extensionRuntimeOptions property is properly initialized. Place this test after the existing 'spec' test (around line 26) to keep initialization tests grouped together.

Test to add:
Create a test named 'extensionRuntimeOptions initialization' that:

1. Creates a new Runtime instance
2. Verifies that extensionRuntimeOptions exists and is defined
3. Checks that it is of type 'object'
4. Confirms it is not null
5. Verifies it can be accessed without throwing a TypeError
6. Optionally, test that properties can be set and retrieved from it

Follow the existing test pattern used in the 'spec' test at lines 11-26, using the tap framework's assertion methods like t.type(), t.ok(), and t.notEqual().

Import In IDE

🤖 Prompt for AI Agents

I have created the following plan after thorough exploration and analysis of the codebase. Follow the below plan verbatim. Trust the files and references. Do not re-verify what's written in the plan. Explore only when absolutely necessary. First implement all the proposed file changes and then I'll review all the changes together at the end.

### Observations

The issue is clear: extensions attempting to access `runtime.extensionRuntimeOptions` encounter a TypeError because this property is not initialized in the Runtime constructor. I found the actual usage in `src/extensions/sp_javascriptV2/index.js` at line 458, where it accesses `this.runtime.extensionRuntimeOptions.javascriptUnsandboxed`. The Runtime constructor follows a consistent pattern of initializing properties with JSDoc documentation. The test files use the `tap` framework and follow clear patterns for verifying property initialization.


### Approach

Add the `extensionRuntimeOptions` property initialization in the Runtime constructor following the existing code patterns. Place it logically near other options objects like `runtimeOptions` and `compilerOptions` (around line 469). Add JSDoc documentation following the established format. Create tests in the existing test file to verify the property exists, is an object, and is accessible without errors.


### Reasoning

I explored the repository structure, read the Runtime constructor section to understand the initialization patterns, examined the test files to understand testing conventions, and searched for existing usage of `extensionRuntimeOptions` to confirm the expected behavior.


## Proposed File Changes

### src/engine/runtime.js(MODIFY)

Add the `extensionRuntimeOptions` property initialization in the Runtime constructor. Insert this after the `compilerOptions` initialization (around line 469, before the `debug` property). Follow the existing JSDoc pattern used for other properties in the constructor.

**JSDoc to add:**
Document the property as an object that holds runtime options for extensions, explaining that extensions can access this to check for specific runtime configuration flags.

**Initialization to add:**
Initialize `this.extensionRuntimeOptions` as an empty object `{}`.

**Placement:**
Insert between the `compilerOptions` initialization (line 465-468) and the `debug` property (line 470). This logical grouping keeps all options-related properties together.

The pattern matches other property initializations in the constructor, such as `runtimeOptions` at lines 459-463 and `compilerOptions` at lines 465-468.

### test/unit/engine_runtime.js(MODIFY)

References: 

- src/engine/runtime.js(MODIFY)

Add a new test case to verify the `extensionRuntimeOptions` property is properly initialized. Place this test after the existing 'spec' test (around line 26) to keep initialization tests grouped together.

**Test to add:**
Create a test named 'extensionRuntimeOptions initialization' that:
1. Creates a new Runtime instance
2. Verifies that `extensionRuntimeOptions` exists and is defined
3. Checks that it is of type 'object'
4. Confirms it is not null
5. Verifies it can be accessed without throwing a TypeError
6. Optionally, test that properties can be set and retrieved from it

Follow the existing test pattern used in the 'spec' test at lines 11-26, using the `tap` framework's assertion methods like `t.type()`, `t.ok()`, and `t.notEqual()`.

---

Developer Humor

🔧 A tiny fix, but oh so grand,\n> Two lines of code, carefully planned.\n> Extensions rejoice, no more TypeError dread,\n> Just an empty object, properly fed!\n> {} saves the day, hip hip hooray! 🎉

---

Execution Information

Branch: develop
Commit: 065a453

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.