Checkpoint storage setting + settings view redesign

[cte]

Context

• Break the SettingsView up into individual components for each section
• Add a checkpoints section
• Convert a bunch of things to Tailwind
• Try to make some things prettier

settings.mp4

Implementation

Screenshots

before	after

How to Test

Get in Touch

---

Important

Redesigns the settings view by breaking it into components, adding a checkpoints section, and converting styles to Tailwind, with updates to state management and testing.

• Settings View Redesign:
  • Break SettingsView into individual components: AdvancedSettings, ApiConfigManager, CheckpointSettings, etc.
  • Add checkpoints section with CheckpointSettings component.
  • Convert styles to Tailwind for consistency and improved UI.
• Functionality Changes:
  • Introduce CheckpointStorage type in Cline.ts and ClineProvider.ts for managing checkpoint storage settings.
  • Update ExtensionStateContext to handle new settings and state management.
• UI Components:
  • Add new components: Section, SectionHeader, SettingsFooter, ExperimentalFeature, etc.
  • Use VSCodeCheckbox, VSCodeButton, and other VSCode UI toolkit components for consistent UI elements.
• Testing:
  • Update tests in SettingsView.test.tsx to cover new settings and components.
  • Ensure ExtensionStateContext.test.tsx reflects changes in state management.

^{This description was created by for e1ccb70. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: e1ccb70

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cte]

Working on this as a follow-up.

[cte]

I think we should stop tampering with the non-shadow repo altogether now that the shadow repo implementation has been out for a while.

[ellipsis-dev]

This pull request is quite large, with significant changes across multiple files and components. It includes both refactoring and new feature additions, which could potentially be split into separate pull requests. This would make it easier to review and manage the changes.

Here are some suggestions for splitting the pull request:

1. Refactoring Changes: Consider creating a separate pull request for all the refactoring changes, such as those in src/core/Cline.ts, webview-ui/src/components/common/MermaidBlock.tsx, and webview-ui/src/components/history/HistoryPreview.tsx.

2. New Feature Additions: Create another pull request for the new features, such as the AdvancedSettings, AutoApproveSettings, and BrowserSettings components.

3. Styling Updates: The styling updates, like those in webview-ui/src/components/settings/ApiConfigManager.tsx and webview-ui/src/index.css, could be grouped into a separate pull request.

By splitting the changes into these categories, it will be easier to review and ensure that each set of changes is thoroughly tested and validated. Let me know if you have any questions or need further assistance!

[cte]

All of this logic was copied to a dedicated custom hook to clean this component up a bit.