Aaron Powell
17b174fb0a
* Add keyword display to extension cards on website - Add .resource-keywords and .keyword-tag CSS styles for rendering keyword badges - Update renderExtensionsHtml() to display keywords below extension description - Keywords now visible on the website extensions page with styled badges - Regenerate website data to include keyword metadata Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Canvas manifest implementation for all extensions Add per-extension canvas manifests with: - Structured canvas metadata (name, description, version, keywords) - Screenshot definitions (icon and gallery with path/type) - Relative paths for images within each extension directory Enhance extension metadata: - Generate meaningful descriptions from source analysis - Extract and assign keywords for discoverability - Store metadata in package.json and extension source files Update website rendering and data generation: - Include keywords in extension cards and search index - Add per-extension canvas.json files for independent evolution - Support screenshot metadata in manifest structure - Generate extensions.json with full canonical paths for website All 9 local canvas extensions now have complete manifests with descriptions, keywords, and screenshot references. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Tweaking some descriptions * Fix description priority to prefer package.json over in-source metadata Reverse the priority in canvasDescription so that package.json descriptions (which contain the enhanced, manually-curated descriptions) take precedence over older in-source descriptions extracted from createCanvas(...) calls. This prevents regression when npm run website:data regenerates outputs, ensuring that committed canvas.json files maintain the current descriptions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix canvas validation to skip external.json file The validation script was treating extensions/external.json as if it were a directory, causing false validation failures. Added check to skip files (identified by presence of dot in filename) and only validate actual canvas extension directories. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Awesome GitHub Copilot website
Astro + Starlight site published to https://awesome-copilot.github.com/.
Local development
Run these from the repository root (they generate the data the site needs first):
npm run website:data # generate public/data/*.json from repo content
npm run website:dev # generate data + start the dev server
npm run website:build # full production build
Social preview cards (LinkedIn, etc.)
Shared links render as large preview cards driven by Open Graph / Twitter meta tags.
LinkedIn (and most platforms) read Open Graph — primarily og:image — while Twitter/X
also uses twitter:card=summary_large_image. Most tags are produced automatically:
- Starlight defaults emit
og:title,og:description,og:url,og:type,og:site_name, andtwitter:card=summary_large_image. astro.config.mjs(globalhead) emits the shared image tags:og:image,og:image:width,og:image:height,og:image:alt, andtwitter:image.src/components/Head.astroaddstwitter:title/description,og:image:secure_url,og:image:type, andtwitter:image:alt.
Each page's title and description (StarlightPage frontmatter) flow into the card text,
so keep them clear and benefit-focused.
The image-dimension invariant
og:image:width / og:image:height in astro.config.mjs describe public/images/social-image.png
(currently 2400×1260, ~1.91:1). Crawlers use these dimensions to understand the image and
may use them when selecting/rendering the preview. If you swap the image or add a per-page image
override, update the full image set so every tag stays consistent: og:image,
og:image:width, og:image:height, og:image:alt, and twitter:image (the last one matters
because Head.astro derives og:image:secure_url from twitter:image first).
After deploying
LinkedIn caches scrapes aggressively. To force a refresh and confirm the card renders, run the
changed URL through the LinkedIn Post Inspector.
HTML output alone doesn't prove the live card — verify the deployed image returns HTTP 200 over
HTTPS with Content-Type: image/png and no auth.