Skip to content

Conversation

@QuintonJason
Copy link
Contributor

Description

  • resolve ElementInternals testing support
Screenshot 2025-10-24 at 10 33 31 AM

Fixes #(issue)

Type of change

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Run the test suite and verify that the ElementInternal console.log message is not present

  • unit tests
  • e2e tests

Test Configuration:

  • Pine versions:
  • OS:
  • Browsers:
  • Screen readers:
  • Misc:

Checklist:

If not applicable, leave options unchecked.

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing tests pass locally with my changes
  • Design has QA'ed and approved this PR

@netlify
Copy link

netlify bot commented Oct 24, 2025

Deploy Preview for pine-design-system ready!

Name Link
🔨 Latest commit 861503f
🔍 Latest deploy log https://app.netlify.com/projects/pine-design-system/deploys/68ff91e718d912000840680f
😎 Deploy Preview https://deploy-preview-570--pine-design-system.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@github-actions github-actions bot added bug Something isn't working package: core Changes have been made to the Core package labels Oct 24, 2025
@QuintonJason
Copy link
Contributor Author

@coderabbitai review this pr please

@coderabbitai
Copy link

coderabbitai bot commented Oct 24, 2025

@QuintonJason: I'll review the PR changes for you now.

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@coderabbitai
Copy link

coderabbitai bot commented Oct 24, 2025

📝 Walkthrough

Walkthrough

The changes introduce a global test setup infrastructure with a mocked ElementInternals API. A new test setup module is created containing a MockElementInternals class that manages form-related internal state and validity checking. This setup is integrated into the Stencil test configuration via setupFilesAfterEnv, and the TypeScript configuration is updated to handle the new setup file. The setup module is marked for exclusion from coverage reporting.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
Description Check ❓ Inconclusive The pull request description follows the template structure but lacks substantive content in critical sections. While the author has marked the type of change (Bug fix) and provided testing checkpoints (unit and e2e tests), the main Description section is minimal, containing only a checkbox with "resolve ElementInternals testing support" and a screenshot with no explanatory narrative. The issue reference remains as a placeholder ("Fixes #(issue)"), and the test configuration details are empty. The testing rationale is briefly described, but overall context, motivation, and what problem is being resolved are not clearly articulated.
✅ Passed checks (1 passed)
Check name Status Explanation
Title Check ✅ Passed The title "test: resolve element internals testing support issue" accurately describes the main change in the pull request. The changeset introduces a new test setup module that mocks the ElementInternals API and configures it in the test environment, which directly addresses element internals testing support. The title is concise, specific, and uses a conventional commit prefix ("test:") that clearly signals this is a test-related change. It effectively summarizes the primary purpose of the changes without being vague or misleading.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix/elementInternals-test

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (3)
libs/core/src/utils/test/setup.ts (3)

12-15: Clarify @ts-expect-error comments.

The comments state "Stored for mock completeness," but these properties are actively used in setFormValue (lines 38-39). The @ts-expect-error directives appear unnecessary since the properties have valid types and are used correctly.

Consider removing the @ts-expect-error directives and updating the comments to accurately reflect the purpose of these properties:

-  // @ts-expect-error - Stored for mock completeness
   private _formValue: FormData | string | null = null;
-  // @ts-expect-error - Stored for mock completeness
   private _formState: FormData | string | null = null;

67-69: reportValidity implementation is simplified.

The standard ElementInternals.reportValidity() method should fire an "invalid" event when validation fails. This mock only returns the validity state without firing events. For basic unit testing, this simplified implementation may be sufficient, but be aware that tests relying on "invalid" event dispatch will not work correctly.

If tests need to verify "invalid" event handling, consider enhancing the mock:

 reportValidity(): boolean {
+  if (!this.validity.valid) {
+    // Note: Would need element reference to dispatch event properly
+    // For now, this mock doesn't support event dispatch
+  }
   return this.validity.valid;
 }

124-135: Console suppression is narrowly scoped.

The error suppression only filters warnings containing "Property setFormValue was accessed on ElementInternals." Other ElementInternals-related warnings may still appear in test output. This targeted approach is acceptable, but consider expanding the filter if additional warnings emerge during testing.

If needed, you can make the filter more comprehensive:

   if (
     typeof args[0] === 'string' &&
-    args[0].includes('Property setFormValue was accessed on ElementInternals')
+    (args[0].includes('ElementInternals') || args[0].includes('attachInternals'))
   ) {
     return;
   }
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ba80935 and 97aeea3.

📒 Files selected for processing (3)
  • libs/core/src/utils/test/setup.ts (1 hunks)
  • libs/core/stencil.config.ts (1 hunks)
  • libs/core/tsconfig.json (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
  • GitHub Check: test-lint (22)
  • GitHub Check: test-specs (18)
  • GitHub Check: test-specs (20)
  • GitHub Check: test-lint (18)
  • GitHub Check: test-lint (20)
  • GitHub Check: test-specs (22)
  • GitHub Check: Cycode: Vulnerable Dependencies
🔇 Additional comments (4)
libs/core/tsconfig.json (1)

34-34: LGTM! Correct exclusion of test setup file.

Excluding the test setup utility from the main TypeScript compilation is appropriate since it's only used as a side-effect module by the test runner.

libs/core/stencil.config.ts (1)

14-22: LGTM! Testing configuration is correctly structured.

The setupFilesAfterEnv property correctly references the global test setup file, and the coverage exclusion patterns appropriately exclude the setup file from coverage reporting.

libs/core/src/utils/test/setup.ts (2)

34-40: LGTM! Correct setFormValue implementation.

The method correctly handles both the value and optional state parameters, with appropriate fallback logic when state is undefined.


115-119: LGTM! Defensive polyfill implementation.

The conditional check ensures attachInternals is only polyfilled when needed, and the type assertion is appropriate for the mock.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working package: core Changes have been made to the Core package

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants