feat: static import of img source (#52)

app/components/ImageSection.tsx

@@ -1,24 +1,43 @@
 import { ImageZoom } from "fumadocs-ui/components/image-zoom"
 
 interface Props {
-  width: number
-  height: number
+  /**
+   * Image path relative to `/public/img/docs`
+   */
   src: string
   alt?: string
   className?: string
   subtitle?: string
 }
 
-export default function ImageSection({ src, alt, subtitle }: Props) {
+const shimmer = (w: number, h: number) => `
+<svg width="${w}" height="${h}" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+  <defs>
+    <linearGradient id="g">
+      <stop stop-color="#333" offset="20%" />
+      <stop stop-color="#222" offset="50%" />
+      <stop stop-color="#333" offset="70%" />
+    </linearGradient>
+  </defs>
+  <rect width="${w}" height="${h}" fill="#333" />
+  <rect id="r" width="${w}" height="${h}" fill="url(#g)" />
+  <animate xlink:href="#r" attributeName="x" from="-${w}" to="${w}" dur="1s" repeatCount="indefinite"  />
+</svg>`
+
+const toBase64 = (str: string) =>
+  typeof window === "undefined" ? Buffer.from(str).toString("base64") : window.btoa(str)
+
+export default async function ImageSection({ src, alt, subtitle }: Props) {
+  const img = await import(`../../public/img/docs${src}`).then((mod) => mod.default)
+  if (!img) return null
+
   return (
     <div className="mx-auto mb-4 flex flex-col justify-start rounded-lg border border-neutral-200 bg-neutral-100 p-2 dark:border-neutral-800 dark:bg-neutral-900 [&>span]:w-fit [&_img]:m-0">
       <ImageZoom
-        width="0"
-        height="0"
-        className="h-auto w-full rounded-md"
-        sizes="(min-width: 800px) 50vw, 100vw"
+        className="rounded-md"
+        placeholder={`data:image/svg+xml;base64,${toBase64(shimmer(img.width, img.height))}`}
         alt={alt ?? subtitle ?? ""}
-        src={src}
+        src={img}
       />
       {subtitle ? (
         <div className="mx-auto mt-2 flex-shrink whitespace-normal text-pretty break-words text-center text-xs opacity-50">

content/docs/features/stacked-branches.mdx

@@ -14,7 +14,7 @@ This is useful when you have multiple changesets that depend on each other but i
 
 > All of the Pull Request stack orchestration is done locally in the client, which means that your repo content is not shared with a cloud service.
 
-<ImageSection className="mx-auto" src="/img/docs/stacked-branches/0_concepts.jpg" />
+<ImageSection className="mx-auto" src="/stacked-branches/0_concepts.jpg" />
 
 ## Use cases
 
@@ -47,12 +47,12 @@ Stacking and Virtual Branches are similar in that they allow you to separate cod
 the changes are available in your working directory.
 
 The main difference is that Virtual Branches are **independent** from one another, while stacked branches **depend** on the ones that come before it.
-Because of this, the two features are not mutually exclusive but rather complementary. For example a bugfix change that is unrelated to a feature 
+Because of this, the two features are not mutually exclusive but rather complementary. For example a bugfix change that is unrelated to a feature
 can be put in a separate virtual branch. On the other hand, a change that depends on a previous change can be put in a stacked branch above the one it depends on.
 
 In fact GitButler implements stacked branches as Virtual Branches that are split into multiple dependent branches.
 
-<ImageSection src="/img/docs/stacked-branches/11_overview.jpg" />
+<ImageSection src="/stacked-branches/11_overview.jpg" />
 
 ## Workflow
 
@@ -63,49 +63,49 @@ you can create a new dependent branch within a lane by clicking the `+` button a
 
 1. Creating a new dependent branch forms a stack within the lane.
 
-<ImageSection src="/img/docs/stacked-branches/1_creating_stack.jpg" />
+<ImageSection src="/stacked-branches/1_creating_stack.jpg" />
 
 2. New commits land in the top branch of the stack.
 
-<ImageSection src="/img/docs/stacked-branches/2_new_commits.jpg" />
+<ImageSection src="/stacked-branches/2_new_commits.jpg" />
 
 3. Pushing is done for the stack as a whole. Note: The Pull Requests will be created in a way where each branch points to its parent - see [Automatic branch deletion](#automatic-branch-deletion)
 
-<ImageSection src="/img/docs/stacked-branches/3_push_all.jpg" />
+<ImageSection src="/stacked-branches/3_push_all.jpg" />
 
 4. Pull requests must be created one at a time starting from the bottom of the stack.
 
-<ImageSection src="/img/docs/stacked-branches/4_create_pr.jpg" />
+<ImageSection src="/stacked-branches/4_create_pr.jpg" />
 
 5. The PRs will contain a footer with stack information, and as you add more PRs it will keep all up to date.
 
-<ImageSection src="/img/docs/stacked-branches/5_pr_footer.jpg" />
+<ImageSection src="/stacked-branches/5_pr_footer.jpg" />
 
 6. You can drag changes into commits to amend them (e.g. incorporating review feedback) as well as move and squash commits.
 
 <ImageSection
-  src="/img/docs/stacked-branches/6_modify_commits-amend.jpg"
+  src="/stacked-branches/6_modify_commits-amend.jpg"
   subtitle="Amending a commit"
 />
 <ImageSection
-  src="/img/docs/stacked-branches/6_modify_commits-move.jpg"
+  src="/stacked-branches/6_modify_commits-move.jpg"
   subtitle="Moving a commit to a different branch"
 />
 <ImageSection
-  src="/img/docs/stacked-branches/6_modify_commits-squash.jpg"
+  src="/stacked-branches/6_modify_commits-squash.jpg"
   subtitle="Squashing commits"
 />
 
 7. If a change in your stack is independent (e.g. an unrelated bugfix) it can be moved to a different virtual branch (or stack).
    This works for both uncommitted changes and existing commits that you may want to relocate.
 
-<ImageSection src="/img/docs/stacked-branches/7_move_to_vb.jpg" />
+<ImageSection src="/stacked-branches/7_move_to_vb.jpg" />
 
 8. Review/merge your PRs starting from the bottom up. After a PR/branch from your stack has been merged, it is reflected in the Stack and you should force push to reflect the changes
    on the remote as well.
 
-<ImageSection src="/img/docs/stacked-branches/8_merging-1.jpg" />
-<ImageSection src="/img/docs/stacked-branches/8_merging-2.jpg" />
+<ImageSection src="/stacked-branches/8_merging-1.jpg" />
+<ImageSection src="/stacked-branches/8_merging-2.jpg" />
 
 9. When all branches of a stack have been merged, the stack is complete.
 
@@ -125,15 +125,15 @@ Of course, in pure Git terms, a stacked branch will contain all the changes from
 In order to show only the expected Files changed and Commits for PRs in a stack, each PR is created to target the branch below it in the stack.
 This is true for all but the bottom branch in the stack, which targets the default branch of the repository as usual.
 
-<ImageSection src="/img/docs/stacked-branches/9_pr_heads.jpg" />
+<ImageSection src="/stacked-branches/9_pr_heads.jpg" />
 
 > Every branch in the stack contains the commits from the branches below it.
 
 This of course does not mean that a Pull Request should be merged into its parent.
 When the bottom branch is merged on GitHub, **if** the PR branch is deleted,
 GitHub will automatically update any PRs that used to target it to target the default branch instead.
 
-<ImageSection src="/img/docs/stacked-branches/10_branch_deletion.jpg" />
+<ImageSection src="/stacked-branches/10_branch_deletion.jpg" />
 
 If the newly merged branch from the bottom of the stack is not deleted, the next PR in line will still target it and there is a risk of accidentally merging it into the now out of data branch.
 For this reason it is _highly recommended_ to [enable on GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-the-automatic-deletion-of-branches) the automatic deletion of branches after merging.

content/docs/features/timeline.mdx

@@ -11,7 +11,7 @@ Before GitButler does any major action, it records the state of everything (your
 
 <ImageSection
   alt="Virtual Branches Example"
-  src="/img/docs/timeline-01.avif"
+  src="/timeline-01.png"
 />
 
 
@@ -23,14 +23,14 @@ If you hover over any of the entries, you will see a button named "Revert" that
 
 <ImageSection
   alt="Virtual Branches Example"
-  src="/img/docs/timeline-02.png"
+  src="/timeline-02.png"
 />
 
 ## Recovering Content
 Occasionally, GitButler will also take snapshots of files that were changed recently, even if they weren't committed. If this, or any other action, sees changes in files, you can see which ones and view the change by clicking on the file name.
 
 <ImageSection
   alt="Virtual Branches Example"
-  src="/img/docs/timeline-03.avif"
+  src="/timeline-03.png"
 />
 

content/docs/features/virtual-branches/branch-lanes.mdx

@@ -14,7 +14,7 @@ The interface looks something like this:
 
 <ImageSection
   alt="Virtual Branches Example"
-  src="/img/docs/branch-lanes-01.webp"
+  src="/branch-lanes-01.webp"
   subtitle="An example of working on two branches at the same time, while pending upstream changes wait for you to merge them."
 />
 
@@ -30,7 +30,7 @@ The "Target" is the view of the target branch that you've set. It will show you
 
 <ImageSection
   alt="Virtual Branches Example"
-  src="/img/docs/merge-upstream.png"
+  src="/merge-upstream.png"
   subtitle="A screenshot showcasing the Target view."
 />
 
@@ -59,7 +59,7 @@ You can inspect any file change by clicking on the file path. GitButler will exp
 
 <ImageSection
   alt="Virtual Branches Example"
-  src="/img/docs/branch-lanes-03.webp"
+  src="/branch-lanes-03.webp"
   subtitle="Inspecting our file change"
 />
 

content/docs/features/virtual-branches/commits.mdx

@@ -18,7 +18,7 @@ If you want AI to use your diff to generate a commit message, you can hit the "G
 
 <ImageSection
   alt="Creating Commits Example"
-  src="/img/docs/commits-01.gif"
+  src="/commits-01.gif"
 />
 
 ## AI Commit Message Settings
@@ -29,14 +29,14 @@ For both OpenAI and Anthropic, you can either use your own API key to directly s
 
 <ImageSection
   alt="AI Commit Settings"
-  src="/img/docs/commits-02.avif"
+  src="/commits-02.png"
 />
 
 If you use your own key for OpenAI or Anthropic, you can choose which model you would like us to use.
 
 <ImageSection
   alt="AI Commit Settings"
-  src="/img/docs/commits-03.avif"
+  src="/commits-03.png"
 />
 
 If you don't want to send your diff to another server, you can also use Ollama, which is a local LLM server. With Ollama, you can run nearly any open source large language model ([Llama 3](https://www.ollama.com/library/llama3), [Phi 3](https://www.ollama.com/library/phi3), [Mistral](https://www.ollama.com/library/mistral), [Gemma](https://www.ollama.com/library/gemma), etc) entirely locally.
@@ -45,7 +45,7 @@ With all of these models, you can also customize the prompt if you want somethin
 
 <ImageSection
   alt="AI Commit Settings"
-  src="/img/docs/commits-04.avif"
+  src="/commits-04.png"
 />
 
 Custom prompts can contain three variables which we will replace with the appropriate values. Those include:
@@ -63,7 +63,7 @@ This will both rewrite that commit to include the new changes and also rebase ev
 
 <ImageSection
   alt="Absorbing New Work"
-  src="/img/docs/commits-05.gif"
+  src="/commits-05.gif"
 />
 
 ## Undoing Commits
@@ -76,7 +76,7 @@ You can easily undo any commit in your stack by expanding the commit and hitting
 
 <ImageSection
   alt="Undoing Commits"
-  src="/img/docs/commits-06.gif"
+  src="/commits-06.gif"
 />
 
 ## Squashing Commits
@@ -85,7 +85,7 @@ Squashing two commits into a single combined commit is also very simple. Just dr
 
 <ImageSection
   alt="Squashing Commits"
-  src="/img/docs/commits-07.gif"
+  src="/commits-07.gif"
 />
 
 ## Splitting Commits
@@ -94,7 +94,7 @@ Splitting commits is slightly more complex. GitButler allows you to create an "e
 
 <ImageSection
   alt="Splitting Commits"
-  src="/img/docs/commits-08.gif"
+  src="/commits-08.gif"
 />
 
 You can also notice that I easily edit the commit message by just hitting the "edit message" button.
@@ -105,7 +105,7 @@ You can also arbitrarily change the order of your commits by dragging and droppi
 
 <ImageSection
   alt="Moving Commits"
-  src="/img/docs/commits-09.gif"
+  src="/commits-09.gif"
 />
 
 ## Edit Mode
@@ -117,7 +117,7 @@ The screen will go into "Edit mode", indicating that you're in a special state w
 <ImageSection
   subtitle="Editing a commit"
   alt="Editing a commit"
-  src="/img/docs/conflicts-edit-mode.png"
+  src="/conflicts-edit-mode.png"
 />
 
 Then you can change whatever you want and when you click "Save and exit", it will amend the commit you were editing and rebase anything on top of it.

content/docs/features/virtual-branches/committer-mark.mdx

@@ -18,7 +18,7 @@ If you choose to turn it on as a show of support, GitButler will credit itself a
 
 <ImageSection
   alt="Committer Mark"
-  src="/img/docs/committer-01.gif"
+  src="/committer-01.gif"
   subtitle="What a GitButler aided commit looks like on GitHub"
 />
 

content/docs/features/virtual-branches/integration-branch.mdx

@@ -17,7 +17,7 @@ The way that we handle this relatively well is by creating an "integration" comm
 
 <ImageSection
   alt="Viewing Remote Branches"
-  src="/img/docs/integration-01.avif"
+  src="/integration-01.png"
   subtitle="An 'integration' commit example."
 />
 

content/docs/features/virtual-branches/merging.mdx

@@ -14,23 +14,23 @@ When you go to update from upstream, GitButler will show you all the branches th
 
 <ImageSection
   subtitle="One branch has a conflict with the upstream work"
-  src="/img/docs/conflicts-incoming.png"
+  src="/conflicts-incoming.png"
   alt="Conflicts with commits"
 />
 
 In this case, when you perform the rebase, that branch will then contain "conflicted" commits. They will be marked in the UI as conflicted and you can click on them to get a "resolve conflict" button to start the resolution process.
 
 <ImageSection
   subtitle="Resolving a conflict"
-  src="/img/docs/conflicts-conflicted.png"
+  src="/conflicts-conflicted.png"
   alt="Conflicts with commits"
 />
 
 When you click that, GitButler will remove the other virtual branches and other work from your working directory and check out just this commit with it's conflict markers. It will show you a special "edit mode" screen, where you are directly editing this commit.
 
 <ImageSection
   subtitle="Resolving a conflict"
-  src="/img/docs/conflicts-edit.png"
+  src="/conflicts-edit.png"
   alt="Conflicts with commits"
 />
 

content/docs/features/virtual-branches/overview.mdx

@@ -15,7 +15,7 @@ Virtual branches are just like normal Git branches, except that you can work on
 
 <ImageSection
   alt="Virtual Branches Example"
-  src="/img/docs/virtual-branches-01.jpeg"
+  src="/virtual-branches-01.jpeg"
   subtitle="An example of working on two branches at the same time, while pending upstream changes wait for you to merge them."
 />
 
@@ -50,18 +50,18 @@ Each time you commit on a virtual branch, GitButler calculates what that branch
 ## Applying and Unapplying Branches
 Since there isn't just a single branch you can be on, you don't "switch" branches, which implies replacement. You simply "apply" branches, which takes whatever changes they represent and adds them to your working directory. If you don't want those changes in your working directory anymore, you can "unapply" them, which removes only those changes.
 
-<ImageSection subtitle="Click 'unapply' for any branch to stash it and remove it's changes from the working directory" src="/img/docs/virtual-branches-02.jpeg" alt="Virtual Branch Apply / Unapply" />
+<ImageSection subtitle="Click 'unapply' for any branch to stash it and remove it's changes from the working directory" src="/virtual-branches-02.jpeg" alt="Virtual Branch Apply / Unapply" />
 
 To delete a virtual branch, you simply unapply it, then left click on it and choose "delete".
 
 ## Merging Upstream
 Eventually you will have work merged into the branch you chose as your target branch, which will need to be reconciled with all your virtual branches to keep them up to date with where they will eventually need to merge to.
 
-<ImageSection subtitle="Click 'Merge into common base' to integrate upstream changes into your virtual branches." src="/img/docs/merge-upstream.png" alt="Branch Commit List" />
+<ImageSection subtitle="Click 'Merge into common base' to integrate upstream changes into your virtual branches." src="/merge-upstream.png" alt="Branch Commit List" />
 
 Upstream work will automatically be shown in your sidebar in the "Target" section. When you click "Merge into common base" (or the "Update" button next to your "Workspace" section), we will attempt to integrate that work with your existing virtual branches. Each branch, applied or unapplied, will try to be updated with the new work.
 
-<ImageSection subtitle="Click 'Update workspace' to integrate upstream changes into your virtual branches." src="/img/docs/merge-upstream-incoming.png" alt="Update Workspace" />
+<ImageSection subtitle="Click 'Update workspace' to integrate upstream changes into your virtual branches." src="/merge-upstream-incoming.png" alt="Update Workspace" />
 
 For each virtual branch you have, we will show you if the incoming upstream work has conflicts with each branch. If there are conflicts, you can choose to stash the branch or go ahead and rebase with conflicts, which you can fix later.
 
@@ -72,15 +72,15 @@ If you do rebase work that has conflicts, the commit will be marked as being in
 
 <ImageSection 
   subtitle="When your commits have conflicts" 
-  src="/img/docs/conflicts-commits.png"
+  src="/conflicts-commits.png"
   alt="Conflicts with commits"
 />
 
 This is different from how you might have dealt with conflicts in Git before. If there is conflicting work in a commit, GitButler will ignore the parts that conflict and keep rebasing. In other words, rebases _always_ work. Then you can focus resolving each conflicted commit, one at a time.
 
 <ImageSection
   subtitle="Resolving a conflict"
-  src="/img/docs/conflicts-resolve.png"
+  src="/conflicts-resolve.png"
   alt="Conflicts with commits"
 />
 

content/docs/features/virtual-branches/pushing-and-fetching.mdx

@@ -12,7 +12,7 @@ You can set your preference (and test if it works) in your project's "Git authen
 
 <ImageSection
   alt="Git Authentication Settings"
-  src="/img/docs/pushing.png"
+  src="/pushing.png"
 />
 
 Once that's done, GitButler will be able to automatically fetch upstream work and push new branches to your upstream server.