Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactored: src/screens/OrgSettings from Jest to Vitest(fixes: #2567) #2625

Open
wants to merge 5 commits into
base: develop-postgres
Choose a base branch
from

Conversation

devender18
Copy link

@devender18 devender18 commented Dec 9, 2024

What kind of change does this PR introduce?
Refactoring

Issue Number:

Fixes #2567

Did you add tests for your changes?
No

Snapshots/Videos:
Screenshot 2024-12-10 at 4 40 49 PM

Screenshot 2024-12-10 at 5 44 44 PM

If relevant, did you update the documentation?
Not Relavant

Summary
This PR migrates the existing tests for OrgSetting.tsx from Jest to Vitest

Does this PR introduce a breaking change?
No

Other information

Have you read the contributing guide?
Yes

Summary by CodeRabbit

  • Tests
    • Updated the test suite for the OrgSettings component for improved clarity and functionality.
    • Added new tests for dropdown rendering in settings tabs.
    • Adjusted existing tests for URL parameter handling and error message assertions.

Copy link

coderabbitai bot commented Dec 9, 2024

Walkthrough

The changes in this pull request involve refactoring the test suite for the OrgSettings component from Jest to Vitest. Key modifications include reorganizing import statements, updating the renderOrganisationSettings function to accept an optional orgId, and transitioning mock management from beforeAll and afterAll to afterEach. The tests have been adjusted to utilize the new mock structure, ensuring they check for the correct rendering and behavior of the OrgSettings component under various conditions.

Changes

File Change Summary
src/screens/OrgSettings/OrgSettings.spec.tsx Reorganized imports, updated renderOrganisationSettings function, transitioned to afterEach for mocks, modified test cases for URL parameters, and added a new test for dropdown rendering.

Assessment against linked issues

Objective Addressed Explanation
Replace Jest-specific functions and mocks with Vitest equivalents (#2567)
Ensure all tests in src/screens/OrgSettings pass after migration (#2567)
Maintain the test coverage for the file as 100% after migration (#2567)

Possibly related issues

Possibly related PRs

Suggested labels

refactor

Suggested reviewers

  • pranshugupta54
  • varshith257

Poem

🐰 In the land of tests so bright,
We hopped from Jest to Vitest light.
With mocks restored and clarity gained,
Our OrgSettings tests are now unchained!
So let us cheer, for changes made,
A smoother path for tests we laid! 🎉


📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between bbce0c1 and 72f1420.

📒 Files selected for processing (1)
  • src/screens/OrgSettings/OrgSettings.spec.tsx (4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/screens/OrgSettings/OrgSettings.spec.tsx

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Experiment)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

github-actions bot commented Dec 9, 2024

Our Pull Request Approval Process

Thanks for contributing!

Testing Your Code

Remember, your PRs won't be reviewed until these criteria are met:

  1. We don't merge PRs with poor code quality.
    1. Follow coding best practices such that CodeRabbit.ai approves your PR.
  2. We don't merge PRs with failed tests.
    1. When tests fail, click on the Details link to learn more.
    2. Write sufficient tests for your changes (CodeCov Patch Test). Your testing level must be better than the target threshold of the repository
    3. Tests may fail if you edit sensitive files. Ask to add the ignore-sensitive-files-pr label if the edits are necessary.
  3. We cannot merge PRs with conflicting files. These must be fixed.

Our policies make our code better.

Reviewers

Do not assign reviewers. Our Queue Monitors will review your PR and assign them.
When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

  1. comments in this PR or
  2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

  1. arbitrators of future discussions with other contributors about the validity of your changes
  2. point of contact for evaluating the validity of your work
  3. person who verifies matching issues by others that should be closed.
  4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

  1. PRs with issues not assigned to you will be closed by the reviewer
  2. Fix the first comment in the PR so that each issue listed automatically closes

Other

  1. 🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
  2. Read the CONTRIBUTING.md file make

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: 0

🧹 Outside diff range and nitpick comments (1)
src/screens/OrgSettings/OrgSettings.test.tsx (1)

Line range hint 1-102: Migration successfully maintains test integrity

The migration from Jest to Vitest has been implemented cleanly while:

  • Preserving all test scenarios and assertions
  • Maintaining proper test structure and organization
  • Following testing-library best practices
  • Keeping the same level of component coverage

This aligns well with the PR objectives of refactoring without adding new tests or changing functionality.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 0630cff and fe11bea.

📒 Files selected for processing (1)
  • src/screens/OrgSettings/OrgSettings.test.tsx (2 hunks)
🔇 Additional comments (4)
src/screens/OrgSettings/OrgSettings.test.tsx (4)

45-47: LGTM! Correct migration of Jest mocks to Vitest

The migration from jest.mock to vi.mock and jest.requireActual to vi.importActual is implemented correctly, maintaining the same mocking functionality for the router's useParams hook.


52-52: LGTM! Correct migration of cleanup method

The migration from jest.clearAllMocks to vi.clearAllMocks is implemented correctly in the afterAll hook.


5-5: Verify if location mocking is still needed

The removal of jest-location-mock is noted. If location mocking is still required for these tests, consider using Vitest's built-in location mocking capabilities or a compatible alternative.

✅ Verification successful

Removal of jest-location-mock import is appropriate

Since there are no location-related assertions, mocks, or manipulations in either the component or its test file, the removal of jest-location-mock import is correct and doesn't require any replacement in the Vitest migration.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any location-related test assertions or mocks
rg -i "location|window\.location|history" "src/screens/OrgSettings/OrgSettings.tsx"

Length of output: 83


Script:

#!/bin/bash
# Let's check the test file itself for any location-related assertions or mocks
rg -i "location|window\.location|history" "src/screens/OrgSettings/OrgSettings.test.tsx"

# Also check for any location-related setup or cleanup in the test file
ast-grep --pattern 'beforeEach($$$)' "src/screens/OrgSettings/OrgSettings.test.tsx"
ast-grep --pattern 'afterEach($$$)' "src/screens/OrgSettings/OrgSettings.test.tsx"

Length of output: 255


Line range hint 55-102: Verify test coverage remains at 100%

The test implementation looks comprehensive, covering routing, component rendering, and user interactions. However, as per PR objectives, we need to verify that the test coverage remains at 100% after the migration.

coderabbitai[bot]
coderabbitai bot previously approved these changes Dec 9, 2024
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: 0

🧹 Outside diff range and nitpick comments (3)
src/screens/OrgSettings/OrgSettings.spec.tsx (3)

Line range hint 19-49: Consider separating mocking logic from rendering

The helper function currently handles both mocking and rendering, which could make it harder to maintain and test different scenarios. Consider splitting these responsibilities:

-const renderOrganisationSettings = (link = link1, orgId = 'orgId'): void => {
+const mockRouterParams = (orgId: string | undefined) => {
   vi.doMock('react-router-dom', async () => {
     const actual = await vi.importActual('react-router-dom');
     return {
       ...actual,
       useParams: () => ({ orgId }),
     };
   });
+};
 
+const renderOrganisationSettings = (link = link1, orgId = 'orgId'): void => {
+  mockRouterParams(orgId);
   render(
     // ... rest of the rendering logic
   );
 };

This separation would:

  1. Make it easier to test different routing scenarios
  2. Improve function reusability
  3. Make the code more maintainable

52-54: Consider using more specific mock restorations

Instead of restoring all mocks, consider restoring only the specific mocks used in each test. This provides better isolation and makes it clearer which mocks are being used.

-  afterEach(() => {
-    vi.restoreAllMocks();
-  });
+  afterEach(() => {
+    vi.unmock('react-router-dom');
+  });

Line range hint 95-122: Enhance test assertions for better coverage

The main test case could benefit from more specific assertions to ensure proper component behavior.

   it('should render the organisation settings page', async () => {
     renderOrganisationSettings();
 
     await waitFor(() => {
       expect(screen.getByTestId('generalSettings')).toBeInTheDocument();
+      expect(screen.getByTestId('generalSettings')).toHaveTextContent('General Settings');
       // ... other assertions
     });
 
     userEvent.click(screen.getByTestId('generalSettings'));
     await waitFor(() => {
       expect(screen.getByTestId('generalTab')).toBeInTheDocument();
+      expect(screen.getByTestId('generalTab')).toBeVisible();
     });
     // ... rest of the test
   });
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between fe11bea and 418899f.

📒 Files selected for processing (1)
  • src/screens/OrgSettings/OrgSettings.spec.tsx (4 hunks)
🔇 Additional comments (4)
src/screens/OrgSettings/OrgSettings.spec.tsx (4)

1-18: LGTM! Imports and setup are properly migrated to Vitest

The import statements and initial setup are correctly organized, with appropriate testing utilities from Vitest replacing Jest equivalents.


124-137: LGTM! Dropdown test is well-structured

The dropdown test case is well-written with clear assertions and proper user interaction simulation.


56-87: 🛠️ Refactor suggestion

Optimize the redirect test implementation

The current implementation re-imports the OrgSettings component unnecessarily and duplicates rendering logic.

   it('should redirect to fallback URL if URL params are undefined', async () => {
-    const useParamsMock = vi.fn(() => ({ orgId: undefined }));
-    vi.doMock('react-router-dom', async () => {
-      const actual = await vi.importActual('react-router-dom');
-      return {
-        ...actual,
-        useParams: useParamsMock,
-      };
-    });
-
-    const { default: OrgSettings } = await import('./OrgSettings');
-
-    render(
-      <MockedProvider addTypename={false}>
-        <MemoryRouter initialEntries={['/orgsetting/']}>
-          // ... rest of the providers
-      </MockedProvider>,
-    );
+    renderOrganisationSettings(link1, undefined);

Likely invalid or redundant comment.


Line range hint 1-137: Verify test coverage meets requirements

The PR objectives specify maintaining 100% test coverage. While the tests appear comprehensive, please ensure all edge cases are covered:

  1. Error states in the settings tabs
  2. Network error scenarios
  3. Loading states
✅ Verification successful

Test coverage appears complete and well-structured

After analyzing the component and its tests:

  1. The component itself is relatively simple, mainly handling routing and tab switching
  2. The test file covers all main scenarios:
    • Routing with valid and invalid orgId
    • Rendering of all three settings tabs
    • Tab switching functionality
    • Dropdown menu functionality
  3. The component delegates complex functionality to child components (GeneralSettings, OrgActionItemCategories, OrganizationAgendaCategory)
  4. The only ignored coverage is a dropdown click handler marked with /* istanbul ignore next */, which is redundant as the same functionality is tested via button clicks

The test coverage is appropriate for this component's responsibilities, as:

  • There are no direct API calls in this component
  • Error handling is delegated to child components
  • Loading states are managed by child components
  • All user interactions (tab switching, dropdown) are tested
  • Route handling for missing orgId is tested
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check test coverage for the OrgSettings component

# Look for any untested error handlers or loading states
ast-grep --pattern 'catch ($err) { $$$ }' src/screens/OrgSettings/OrgSettings.tsx
ast-grep --pattern 'loading ? $$$ : $$$' src/screens/OrgSettings/OrgSettings.tsx

Length of output: 166


Script:

#!/bin/bash
# Let's first check if the file exists and see its content
fd OrgSettings.tsx$ --exec cat {}

# Also check for any loading or error states in the component's queries
rg -A 2 "useQuery|useMutation" src/screens/OrgSettings/OrgSettings.tsx

# Check test mocks to see what scenarios are covered
fd OrgSettings.mocks --exec cat {}

Length of output: 8033

coderabbitai[bot]
coderabbitai bot previously approved these changes Dec 10, 2024
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: 0

🧹 Outside diff range and nitpick comments (3)
src/screens/OrgSettings/OrgSettings.spec.tsx (3)

19-27: Consider adding error handling for mock setup

The mock implementation is clean and follows Vitest best practices. However, consider adding error handling for the mock setup to make it more robust.

 const mockRouterParams = (orgId: string | undefined): void => {
   vi.doMock('react-router-dom', async () => {
+    try {
       const actual = await vi.importActual('react-router-dom');
       return {
         ...actual,
         useParams: () => ({ orgId }),
       };
+    } catch (error) {
+      console.error('Failed to mock router params:', error);
+      throw error;
+    }
   });
 };

Line range hint 28-52: Add return type annotation for better type safety

The render function implementation is solid, but could benefit from explicit return type annotation.

-const renderOrganisationSettings = (link = link1, orgId = 'orgId'): void => {
+const renderOrganisationSettings = (link = link1, orgId = 'orgId'): ReturnType<typeof render> => {
   mockRouterParams(orgId);
-  render(
+  return render(

58-94: Consider consolidating import and mock setup

The redirection test has duplicate mock setup code. Consider extracting it to a helper function.

+const setupRedirectTest = async () => {
+  const useParamsMock = vi.fn(() => ({ orgId: undefined }));
+  await vi.doMock('react-router-dom', async () => {
+    const actual = await vi.importActual('react-router-dom');
+    return {
+      ...actual,
+      useParams: useParamsMock,
+    };
+  });
+  return (await import('./OrgSettings')).default;
+};

 it('should redirect to fallback URL if URL params are undefined', async () => {
-  const useParamsMock = vi.fn(() => ({ orgId: undefined }));
-  vi.doMock('react-router-dom', async () => {...});
-  const { default: OrgSettings } = await import('./OrgSettings');
+  const OrgSettings = await setupRedirectTest();
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 418899f and 7255e37.

📒 Files selected for processing (1)
  • src/screens/OrgSettings/OrgSettings.spec.tsx (4 hunks)
🔇 Additional comments (5)
src/screens/OrgSettings/OrgSettings.spec.tsx (5)

1-18: LGTM: Imports are properly organized and updated for Vitest

The transition from Jest to Vitest is correctly reflected in the imports, maintaining all necessary testing utilities while adding Vitest-specific ones.


54-56: LGTM: Proper cleanup implementation

The cleanup using afterEach follows Vitest best practices for unmocking.


127-140: LGTM: Comprehensive dropdown testing

The dropdown test provides good coverage of the UI interaction and verification of dropdown items.


Line range hint 1-140: Verify test coverage metrics

The migration to Vitest appears successful. Let's verify the test coverage remains at 100% as per PR objectives.

✅ Verification successful

Test coverage configuration and implementation verified successfully

The verification shows:

  • Coverage is properly configured in vitest.config.ts with Istanbul provider
  • No skipped, disabled, or pending tests found
  • All test cases are properly implemented with complete test bodies
  • The test file maintains comprehensive coverage of the component's functionality including:
    • URL parameter handling
    • Component rendering
    • User interactions
    • Navigation scenarios
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Look for coverage configuration
rg -l "coverage" -g "*.{json,js,ts}"

# Check for any skipped or disabled tests
rg -e "skip\(" -e "skip:" -e "disabled" src/screens/OrgSettings/OrgSettings.spec.tsx

Length of output: 182


Script:

#!/bin/bash
# Check coverage configuration in vitest config
cat vitest.config.ts

# Check test file for any pending or incomplete tests
ast-grep --pattern 'it.todo($_)' src/screens/OrgSettings/OrgSettings.spec.tsx
ast-grep --pattern 'it.skip($_)' src/screens/OrgSettings/OrgSettings.spec.tsx
ast-grep --pattern 'describe.skip($_)' src/screens/OrgSettings/OrgSettings.spec.tsx

# Check test implementation completeness
ast-grep --pattern 'it($_, $_) {
  $$$
}' src/screens/OrgSettings/OrgSettings.spec.tsx

Length of output: 1247


Line range hint 97-125: Verify test coverage for error scenarios

While the happy path is well tested, consider adding tests for error scenarios.

Consider adding the following test cases:

  • Network error handling
  • Invalid organization ID
  • Loading states

coderabbitai[bot]
coderabbitai bot previously approved these changes Dec 10, 2024
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: 0

🧹 Outside diff range and nitpick comments (5)
src/screens/OrgSettings/OrgSettings.spec.tsx (5)

20-33: Consider improving error handling in mockRouterParams

While the error handling is good, logging to console in tests isn't ideal as it can clutter test output.

Consider this improvement:

 } catch (error) {
-  console.error('Failed to mock router params:', error);
   throw error;
 }

67-78: Consider strengthening SetupRedirectTest assertions

The setup function is well-structured, but consider adding type assertions for better type safety.

-const useParamsMock = vi.fn(() => ({ orgId: undefined }));
+const useParamsMock = vi.fn<[], { orgId: undefined }>(() => ({ orgId: undefined }));

101-106: Consider adding timing assertions

When testing redirects, it's good practice to assert that the redirect happens within a reasonable timeframe.

-await waitFor(() => {
+await waitFor(() => {
   const paramsErrorElement = screen.getByTestId('paramsError');
   expect(paramsErrorElement).toBeInTheDocument();
   expect(paramsErrorElement.textContent).toBe('Redirected to Home');
-});
+}, { timeout: 1000 });

139-152: Strengthen dropdown test assertions

The new dropdown test is good but could be more thorough.

Consider adding these assertions:

// Verify dropdown is closed initially
expect(screen.queryByRole('listbox')).not.toBeInTheDocument();

// After clicking
userEvent.click(screen.getByTestId('settingsDropdownToggle'));

// Verify specific items and their order
const items = screen.getAllByRole('button');
expect(items[0]).toHaveTextContent(/general/i);
expect(items[1]).toHaveTextContent(/actionItemCategories/i);
expect(items[2]).toHaveTextContent(/agendaItemCategories/i);

Test coverage needs attention for dropdown click handler

The test coverage is mostly complete, but there's an explicitly ignored test coverage area:

  • The dropdown item's onClick handler is marked with /* istanbul ignore next */, but this functionality should be tested as it's a core interaction path.

Current tests verify:

  • Redirect behavior for missing orgId
  • Rendering of all settings tabs
  • Tab switching via main buttons
  • Dropdown presence and item count

But missing:

  • Tab switching via dropdown items, which is explicitly excluded from coverage
🔗 Analysis chain

Line range hint 1-152: Verify test coverage meets PR requirements

The PR objectives specify maintaining 100% test coverage after migration.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify test coverage for OrgSettings component

# Search for coverage configuration
echo "Checking coverage configuration..."
rg -l "coverage" .

# Search for any skipped or commented out tests
echo "Checking for skipped tests..."
rg -i "skip|todo|disabled" src/screens/OrgSettings/OrgSettings.spec.tsx

# Search for untested component methods
echo "Checking for potential untested methods..."
ast-grep --pattern 'export default function OrgSettings() {
  $$$
}' src/screens/OrgSettings/OrgSettings.tsx

Length of output: 545


Script:

#!/bin/bash
# Let's examine the coverage configuration and component implementation more thoroughly

# Check coverage configuration in vitest config
echo "Checking vitest coverage configuration..."
cat vitest.config.ts

# Examine the actual component implementation
echo "Checking OrgSettings implementation..."
cat src/screens/OrgSettings/OrgSettings.tsx

# Look for any conditional renders or handlers that might need testing
echo "Searching for conditional renders and handlers..."
rg -A 3 "if|switch|case|handle|onClick|onChange" src/screens/OrgSettings/OrgSettings.tsx

Length of output: 6976

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 7255e37 and bbce0c1.

📒 Files selected for processing (1)
  • src/screens/OrgSettings/OrgSettings.spec.tsx (4 hunks)
🔇 Additional comments (3)
src/screens/OrgSettings/OrgSettings.spec.tsx (3)

1-14: LGTM: Imports successfully migrated to Vitest

The import statements have been correctly updated to use Vitest testing utilities while maintaining all necessary dependencies for the component testing.


Line range hint 34-60: LGTM: Render utility properly configured

The renderOrganisationSettings function is well structured with:

  • Proper default parameters
  • Complete provider hierarchy
  • Correct routing setup

63-65: LGTM: Proper cleanup in afterEach

The cleanup of router mocks in afterEach ensures a clean state for each test.

coderabbitai[bot]
coderabbitai bot previously approved these changes Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants