Move static assets in docs/ dir and build JS&CSS in docs/ dir too

README.md

@@ -121,7 +121,7 @@ If this is a one-time submission and you don't want to bother, you can just add
 
 The excerpt is a small description of the guide content that will show on the guide list so users can have a glimpse of what the guide is about. Be clear and concise!
 
-Images go under [`src/images`](https://github.com/bump-sh/docs/tree/main/src/images) and can be called with `![](/images/guides/<your_image_name>)`.
+Images go under [`src/docs/images`](https://github.com/bump-sh/docs/tree/main/src/docs/images) and can be called with `![](/docs/images/guides/<your_image_name>)`.
 
 ##### Gotchas
 * Ordered lists: if you need to any kind of blocks in your ordered list item, make sure it immediately follows the numbered paragraph line (no empty line in between). You might also want to [indent your block to line up with the first non-space character after the list item marker](https://stackoverflow.com/questions/34987908/embed-a-code-block-in-a-list-item-with-proper-indentation-in-kramdown). Just do both for safety!

bridgetown.config.yml

@@ -25,9 +25,10 @@ template_engine: erb
 include: ["_redirects"]
 
 metadata:
-  favicon_light: "/images/favicon.svg"
-  favicon_dark: "/images/favicon-dark.svg"
+  favicon_light: "/docs/images/favicon.svg"
+  favicon_dark: "/docs/images/favicon-dark.svg"
 
+keep_files: ["docs"]
 # Other options you might want to investigate:
 #
 # base_path: "/" # the subpath of your site, e.g. /blog. If you set this option,

esbuild.config.js

@@ -40,7 +40,11 @@ const esbuildOptions = {
   ],
   globOptions: {
     excludeFilter: /\.(dsd|lit)\.css$/
-  }
+  },
+  bridgetownConfig: {
+    destination: "output/docs",
+  },
+  publicPath: "/docs/_bridgetown/static",
 }
 
 build(esbuildOptions)

frontend/styles/atoms/blockquote.css

@@ -1,7 +1,7 @@
 :where(blockquote) {
   --callout-bg-color: var(--bg-color-secondary);
   --callout-border-color: var(--border-color-default);
-  --callout-icon-path: url(/images/icons/info.svg);
+  --callout-icon-path: url(/docs/images/icons/info.svg);
   border-left: 3px solid var(--border-color-default);
   margin-inline: 0;
   padding: var(--spacing-1) var(--spacing-3);
@@ -19,7 +19,7 @@
   &:where(.info, .success, .warning, .error) {
     --callout-bg-color: var(--bg-color-secondary);
     --callout-border-color: var(--border-color-default);
-    --callout-icon-path: url(/images/icons/info.svg);
+    --callout-icon-path: url(/docs/images/icons/info.svg);
 
     background-color: var(--callout-bg-color);
     border-left: 4px solid var(--callout-border-color);
@@ -45,25 +45,25 @@
     &.info {
       --callout-bg-color: var(--bg-color-info);
       --callout-border-color: var(--text-color-info);
-      --callout-icon-path: url(/images/icons/info.svg);
+      --callout-icon-path: url(/docs/images/icons/info.svg);
     }
 
     &.success {
       --callout-bg-color: var(--bg-color-success);
       --callout-border-color: var(--text-color-success);
-      --callout-icon-path: url(/images/icons/success.svg);
+      --callout-icon-path: url(/docs/images/icons/success.svg);
     }
 
     &.warning {
       --callout-bg-color: var(--bg-color-warning);
       --callout-border-color: var(--text-color-warning);
-      --callout-icon-path: url(/images/icons/warning.svg);
+      --callout-icon-path: url(/docs/images/icons/warning.svg);
     }
 
     &.error {
       --callout-bg-color: var(--bg-color-error);
       --callout-border-color: var(--text-color-error);
-      --callout-icon-path: url(/images/icons/error.svg);
+      --callout-icon-path: url(/docs/images/icons/error.svg);
     }
   }
 }

frontend/styles/components/search.css

@@ -1,6 +1,6 @@
 bridgetown-search-form {
   input[type="search"] {
-    background: var(--bg-color) url(/images/icons/search.svg) left var(--spacing-3) center no-repeat;
+    background: var(--bg-color) url(/docs/images/icons/search.svg) left var(--spacing-3) center no-repeat;
     width: 100%;
     padding-left: var(--spacing-9);
   }

src/_components/guides/authors/card.erb

@@ -13,12 +13,12 @@
       <div class="links">
         <% if @author.email.present? %>
           <a href="<%= "mailto:#{@author.email}" %>">
-            <%= svg "images/icons/mail.svg" %>
+            <%= svg "/docs/images/icons/mail.svg" %>
           </a>
         <% end %>
         <% if @author.github.present? %>
           <a href="<%= @author.github %>">
-            <%= svg "images/icons/github.svg" %>
+            <%= svg "/docs/images/icons/github.svg" %>
           </a>
         <% end %>
       </div>

src/_components/guides/in_depth/post_info.erb

@@ -5,7 +5,7 @@
       <%= author_name(author) %>
       <% if !is_guest?(author) && github_link(author).present? %>
         <%= link_to github_link(author), "aria-label": "Go to GitHub" do %>
-          <%= svg "images/icons/github.svg" %>
+          <%= svg "/docs/images/icons/github.svg" %>
         <% end %>
       <% end %>
     <% end %>

src/_components/guides/list.erb

@@ -12,7 +12,7 @@
   <% if @remaining_count > 0 %>
     <a href="<%= relative_url "/guides/#{Bridgetown::Utils.slugify(@category_name)}" %>" class="card browse-all">
       <span>Browse <strong><%= @remaining_count %> more </strong> guides</span>
-      <%= svg "images/icons/arrow-right-circle.svg" %>
+      <%= svg "/docs/images/icons/arrow-right-circle.svg" %>
     </a>
   <% end %>
 </guide-list>

src/_components/guides/version_selector.erb

@@ -2,7 +2,7 @@
   <button class="dropdown-trigger" data-toggle-target="button" data-action="toggle#click" aria-haspopup="true" aria-expanded="false">
     <span class="dropdown-label"><%= @current_version %></span>
     <span class="dropdown-caret">
-      <%= svg "images/icons/caret-right.svg" %>
+      <%= svg "/docs/images/icons/caret-right.svg" %>
     </span>
   </button>
   <div class="dropdown-menu" data-toggle-target="item" data-toggle-active="false" role="menu">
@@ -11,7 +11,7 @@
         <% if version == @current_version %>
           <li class="dropdown-item is-current" aria-current="true" data-action="click->toggle#click">
             <span><%= version %></span>
-            <%= svg "images/icons/checkmark.svg" %>
+            <%= svg "/docs/images/icons/checkmark.svg" %>
           </li>
         <% elsif page_exist_in_version?(version) %>
           <li class="dropdown-item">

src/_components/shared/bump_cta.erb

@@ -1,4 +1,4 @@
 <bump-cta>
   <p><strong>Bump.sh</strong>, the API doc platform for Tech Writers & Engineers</p>
-  <a class="button" href="<%= "https://bump.sh/users/sign_up?utm_source=content-hub&utm_medium=cta&utm_content=#{@slug}" %>">Get started for free <%= svg "images/icons/arrow-right.svg" %></a>
+  <a class="button" href="<%= "https://bump.sh/users/sign_up?utm_source=content-hub&utm_medium=cta&utm_content=#{@slug}" %>">Get started for free <%= svg "/docs/images/icons/arrow-right.svg" %></a>
 </bump-cta>

src/_components/shared/edit_on_github.erb

@@ -1,4 +1,4 @@
 <a href="<%= github_edit_url(@relative_path) %>" class="button edit-on-github" data-button-style="secondary" data-button-size="small">
-  <%= svg "images/icons/pencil.svg" %>
+  <%= svg "/docs/images/icons/pencil.svg" %>
   Edit on Github
 </a>

src/_components/shared/footer.erb

@@ -13,7 +13,7 @@
     </div>
     <div class="bottom-column">
       <% @site.data.footer.social.each do |entry| %>
-        <a class="link" href="<%= entry.link %>"><img src="<%= relative_url "/images/icons/#{entry.icon}" %>" alt="<%= entry.label %>" /></a>
+        <a class="link" href="<%= entry.link %>"><img src="<%= relative_url "/docs/images/icons/#{entry.icon}" %>" alt="<%= entry.label %>" /></a>
       <% end %>
     </div>
   </div>

src/_components/shared/navbar.erb

@@ -1,6 +1,6 @@
 <header>
   <a href="/">
-    <img src="<%= relative_url '/images/bump-logo.svg' %>" alt="Bump.sh" />
+    <img src="<%= relative_url '/docs/images/bump-logo.svg' %>" alt="Bump.sh" />
   </a>
 
   <nav data-controller="toggle">

src/_components/shared/page_navigation.erb

@@ -1,14 +1,14 @@
 <page-navigation>
   <% if @previous.present? %>
     <%= link_to @previous.resource.relative_url, class: "previous" do %>
-      <%= svg "images/icons/arrow-right.svg" %>
+      <%= svg "/docs/images/icons/arrow-right.svg" %>
       <%= @previous.label %>
     <% end %>
   <% end %>
   <% if @next.present? %>
     <%= link_to @next.resource.relative_url do %>
       <%= @next.label %>
-      <%= svg "images/icons/arrow-right.svg" %>
+      <%= svg "/docs/images/icons/arrow-right.svg" %>
     <% end %>
   <% end %>
 </page-navigation>

src/_components/shared/sidebar/item.erb

@@ -1,6 +1,6 @@
 <side-item id="<%= category_id %>"<% if @items.present? %> aria-expanded="true" data-sidebar-target="expandable"<% end %>>
   <div class="item"<% if @is_current %> aria-current="true"<% elsif @is_parent %>data-current-parent="true"<% end %>>
-    <%= svg "images/icons/#{@icon}.svg" if @icon.present? %>
+    <%= svg "/docs/images/icons/#{@icon}.svg" if @icon.present? %>
     <% if @resource.present? %>
       <a class="link" href="<%= @resource.relative_url %>">
         <%= @label %>
@@ -12,7 +12,7 @@
     <% end %>
     <% if @items.present? %>
       <button data-button-style="secondary" data-button-size="xsmall" aria-controls="<%= category_id %>" data-action="sidebar#toggle" aria-label="<%= @is_current ? "Expand list" : "Hide list" %>">
-        <%= svg "images/icons/caret-right.svg" %>
+        <%= svg "/docs/images/icons/caret-right.svg" %>
       </button>
     <% end %>
   </div>

src/_guides/api-basics/api-architecture-diagrams.md

@@ -1,7 +1,7 @@
 ---
 title: Creating Better API Architecture Diagrams
 authors: Damaso Sanoja
-image: images/guides/api-architecture-diagrams.png
+image: /docs/images/guides/api-architecture-diagrams.png
 canonical_url: https://bump.sh/blog/api-architecture-diagrams
 excerpt: Learn about the various types of API architecture diagrams and some tips for creating them.
 date: 2024-03-25
@@ -31,18 +31,18 @@ That said, here are a few interesting common types of API architecture diagrams:
 
 One way to use an API diagram is to illustrate a specific workflow that consumers need to know about. A sequence diagram often includes the HTTP verb (`GET`, `POST`, `PUT`, or `DELETE`) and resource name for each API call in the diagram. They can also be useful for noting any custom calls (like bulk endpoints) that your API offers.
 
-![API diagram that includes HTTP verb and resource](/images/guides/sequence-diagram.jpg)
+![API diagram that includes HTTP verb and resource](/docs/images/guides/sequence-diagram.jpg)
 
 The API diagram above uses the order of arrows to indicate the order in which the calls should be made. Complex workflows like authentication and authorization often require API calls to be made in a very specific order, so API architecture diagrams can help clarify this.
 
-![API flow diagram](/images/guides/workflow-diagram.png)
+![API flow diagram](/docs/images/guides/workflow-diagram.png)
 _Example of a REST API sequence diagram with swimlanes._
 
 ### Service Architecture Diagrams
 
 Another way to use API architecture diagrams is to show how multiple services are connected and integrated with one another.
 
-![API architecture diagram that shows system integration](/images/guides/service-architecture-diagram.jpg)
+![API architecture diagram that shows system integration](/docs/images/guides/service-architecture-diagram.jpg)
 
 The diagram above shows how an online store’s architecture diagram might look, including the resources, endpoints, and attributes of each resource.
 
@@ -52,7 +52,7 @@ Service Architecture Diagrams help new users get a “lay of the land” when it
 
 Finally, your diagram might be focused on illustrating the internal architecture of your system rather than the external.
 
-![Internal API architecture diagram](/images/guides/internal-architecture-diagram.jpg)
+![Internal API architecture diagram](/docs/images/guides/internal-architecture-diagram.jpg)
 
 These diagrams are useful for other engineers at your company to see how the system is designed so they can better understand errors and debug errors faster. They help new engineers onboard faster, and can serve as a reference point when designing new systems at the company. Finally, they help with internal processes like security audits as knowing all the layers a request goes through before accessing your data can help identify vulnerabilities.
 

src/_guides/api-basics/api-contracts-extended-introduction.md

@@ -1,7 +1,7 @@
 ---
 title: API Contracts - an Extended Introduction
 authors: Sooter Saalu
-image: images/guides/api-contracts-extended-introduction.png
+image: /docs/images/guides/api-contracts-extended-introduction.png
 canonical_url: https://bump.sh/blog/api-contracts-extended-introduction
 excerpt: This guide explains how API contracts can help your business, the best practices to follow, and gives some practical examples.
 date: 2023-11-24

src/_guides/api-basics/asyncapi-vs-openapi.md

@@ -1,7 +1,7 @@
 ---
 title: "AsyncAPI vs. OpenAPI: Which Specification Is Right for Your App?"
 authors: Joanna Wallace
-image: images/guides/asyncapi-vs-openapi.png
+image: /docs/images/guides/asyncapi-vs-openapi.png
 canonical_url: https://bump.sh/blog/asyncapi-vs-openapi
 excerpt: Learn about the basic differences between AsyncAPI and OpenAPI that will help you pick one of them.
 date: 2024-03-25

src/_guides/api-basics/design-reviews.md

@@ -151,14 +151,14 @@ Here's a change which looks like it's probably not going to break anything, it's
 just moving an inline definition of a parameter into a reference, and adding a
 new optional parameter.
 
-![](/images/guides/design-reviews/replaced-with-ref.png)
+![](/docs/images/guides/design-reviews/replaced-with-ref.png)
 
 Unfortunately when copying and pasting some of the reusable parameter
 definitions elsewhere something was changed, and that would be hard to spot
 without having both definitions open on two different monitors and comparing the
 two closely. Thankfully Bump.sh can handle that tedious work for you.
 
-![](/images/guides/design-reviews/breaking-change-detected.png)
+![](/docs/images/guides/design-reviews/breaking-change-detected.png)
 
 Bump.sh automatically filters out inconsequential YAML/JSON changes and automates all of the following:
 
@@ -272,7 +272,7 @@ endpoint that needs more review, etc. then the Preview feature can be used.
 When Bump.sh comments on a pull request with the summary of changes, there is
 also a little link on there marked Preview and this is pretty magical. 
 
-![](/images/guides/design-reviews/preview.png)
+![](/docs/images/guides/design-reviews/preview.png)
 
 Instead of just reviewing the YAML changes and hoping the docs look good when
 you merge, you can go and review the docs to make sure all is good before you
@@ -335,7 +335,7 @@ linting](_guides/bump-sh-tutorials/api-linting-with-vacuum.md) using tools like
 vacuum so that its already handled before even getting humans involved with the
 design review.
 
-![Screenshot from GitHub.com, showing the "GitHub Actions / API Lint Results" check result outputting annotations.](/images/guides/api-linting-with-vacuum/vacuum-annotations.png)
+![Screenshot from GitHub.com, showing the "GitHub Actions / API Lint Results" check result outputting annotations.](/docs/images/guides/api-linting-with-vacuum/vacuum-annotations.png)
 
 With Bump.sh spotting changes and offering previews, vacuum highlighting
 concerns automatically, API design reviews should be a pretty simple affair. 

src/_guides/api-basics/dev-guide-api-design-first.md

@@ -1,7 +1,7 @@
 ---
 title: A Developer's Guide to API Design-First
 authors: phil
-image: images/guides/api-first-design-guide.png
+image: /docs/images/guides/api-first-design-guide.png
 canonical_url: https://bump.sh/blog/dev-guide-api-design-first
 excerpt: Learn about the principles of API design-first and how it can benefit your organization.
 date: 2024-11-15
@@ -125,7 +125,7 @@ Anyone who has been building APIs for more than a few years has probably done th
 
 Here's a quick look at the two workflows for comparison.
 
-![](/images/guides/design-first/code-first-design-first.png)
+![](/docs/images/guides/design-first/code-first-design-first.png)
 
 Whilst there are a few more steps, the time invested on agreeing a contract early on brings massive time benefits through the rest of the API lifecycle.
 

src/_guides/api-basics/how-to-use-document-polymorphism-API.md

@@ -55,7 +55,7 @@ information about total area.
 But only an apartment has a specific floor. And we don't usually care about
 roof tiles unless you live in a house.
 
-![polymorphism diagram](/images/guides/polymorphism_accomodation.png)
+![polymorphism diagram](/docs/images/guides/polymorphism_accomodation.png)
 
 There are many solutions for implementing that into your codebase,
 based on your team, language, framework, architecture, opinions about typed VS object oriented language…
@@ -126,7 +126,7 @@ In this way, polymorphism in REST APIs allows for a more flexible and scalable A
 But API is consumed. And API consumers have to be very aware of this polymorphism.
 At Bump.sh, we are convinced that the best solution is to have a very nice documentation for your API.
 
-![new house request](/images/guides/house_without_discriminator.png)
+![new house request](/docs/images/guides/house_without_discriminator.png)
 
 source: https://bump.sh/demo/hub/support/doc/accommodation-polymorphism
 
@@ -418,7 +418,7 @@ requestBody:
 This is visible in generated documentation, where allowed value is explicitly
 defined as either `flat`, either `house`.
 
-![new flat request](/images/guides/apartment-with-discriminator.png)
+![new flat request](/docs/images/guides/apartment-with-discriminator.png)
 
 [See it live](https://bump.sh/demo/hub/support/doc/accommodation-polymorphism/with-discriminator/operation/operation-post-accommodation#operation-post-accommodation-body)
 

src/_guides/api-basics/what-are-the-different-api-types.md

@@ -1,7 +1,7 @@
 ---
 title: What are the different API types?
 authors: jay
-image: images/guides/different-api-types.png
+image: /docs/images/guides/different-api-types.png
 canonical_url: https://bump.sh/blog/what-are-the-different-api-types
 excerpt: This is an introduction to the various API technologies that exist today, and their main use cases.
 date: 2023-11-09

src/_guides/asyncapi/asyncapi-first-event-driven-api.md

@@ -1,7 +1,7 @@
 ---
 title: "An AsyncAPI Example: Building Your First Event-driven API"
 authors: Michael Nyamande
-image: images/guides/building-event-driven-async-api.png
+image: /docs/images/guides/building-event-driven-async-api.png
 canonical_url: https://bump.sh/blog/asyncapi-first-event-driven-api
 excerpt: Follow this walkthrough tutorial and build and Event-driven API along its documentation.
 date: 2024-03-25
@@ -18,7 +18,7 @@ Let’s break those two ideas down a bit so you can really see what’s going on
 
 An *event* is any change in state or an update that a client might be interested in, like a new user registration or an update in the payment status of a transaction. In an event-driven system, a component known as the *publisher* sends an event to a message broker. The message broker sends the event to all the other components, known as *subscribers*, that have registered to receive that particular event. This allows the components of the system to communicate in real-time without being directly connected to each other.
 
-![Event Driven Architecture](/images/guides/event-driven-architecture.png)
+![Event Driven Architecture](/docs/images/guides/event-driven-architecture.png)
 
 As an example, picture a chat application. When a user sends a message, an event-driven API can immediately notify all the other users in the chat, allowing the message to display in their chat window without needing to refresh the page. In a traditional synchronous API, the client would need to poll the server to check for new messages very often and then update the user.  With event-driven APIs, clients receive real-time updates from the API without constantly polling for changes, making them more efficient when it comes to network resource usage. 
 
@@ -205,7 +205,7 @@ To use Bump.sh and generate your AsyncAPI based documentation, simply [create an
 
 After signing up, fill out the following form with the details of your API:
 
-![Bump.sh onboarding screen](images/guides/bump-sh-onboarding-screen.png)
+![Bump.sh onboarding screen](/docs/images/guides/bump-sh-onboarding-screen.png)
 
 You can then proceed to upload your AsyncAPI file manually or using [Bump.sh CLI](https://github.com/bump-sh/cli).
 

src/_guides/asyncapi/what-is-asyncapi.md

@@ -1,7 +1,7 @@
 ---
 title: What is AsyncAPI?
 authors: jay
-image: images/guides/what-is-asyncapi.png
+image: /docs/images/guides/what-is-asyncapi.png
 canonical_url: https://bump.sh/blog/what-is-asyncapi
 excerpt: AsyncAPI is the most popular specification for describing asynchronous APIs and Event-Driven Architectures.
 date: 2023-10-19