chore: opinionated code refactor

.github/instructions/general.instructions.md

@@ -0,0 +1,29 @@
+---
+applyTo: "**"
+---
+
+# GitHub Copilot Instructions
+
+- Use 4 spaces for indentation
+- Ensure all code passes ESLint checks (`npm run lint`)
+- Fix all lint errors before submitting code
+- Use explicit types for all function parameters and return values
+- Avoid using `any` unless absolutely necessary
+- Organize code into logical modules and folders (e.g., `src/components`, `src/utils`)
+- Place tests next to the code they test, using `.test.ts` or `.spec.ts` suffixes
+- Use npm for package management
+- Keep dependencies up to date and remove unused packages
+- Write unit tests for all new features and bug fixes
+- Use Jest or Vitest for testing
+- Run all tests with `npm test` before pushing changes
+- Use feature branches for new work
+- Write clear, concise commit messages
+- Open a pull request for review before merging to `main`
+- Document public functions and components with JSDoc comments
+- Update the README and other docs for significant changes
+- Store sensitive configuration in `.env` files
+- Never commit `.env` or secrets to version control
+- Ensure all checks pass (lint, build, test) before merging
+
+---
+For questions, contact project maintainers or see CONTRIBUTING.md.

.github/instructions/vscode-extension.instructions.md

@@ -0,0 +1,22 @@
+---
+applyTo: "**"
+---
+
+# GitHub Copilot Instructions for VS Code Extension Projects
+
+> **Note:** These instructions are in addition to the [general project instructions](.github/instructions/general.instructions.md). If there is any overlap, follow the general instructions and refer to this file for VS Code extension–specific requirements.
+
+- Implement and document the `activate` and `deactivate` functions in `extension.ts`
+- Dispose of all resources on deactivation
+- Register all commands in `package.json` under `contributes.commands`
+- Document each command with a clear description
+- Document public functions, classes, and extension APIs with JSDoc comments
+- Include usage instructions and examples in the README
+- Validate that the extension builds and runs in the VS Code Extension Host
+
+**Useful Links:**
+- [VS Code API Reference](https://code.visualstudio.com/api/references/vscode-api)
+- [VS Code Extension Authoring Guide](https://code.visualstudio.com/api/get-started/your-first-extension)
+- [VS Code Extension Samples](https://github.com/microsoft/vscode-extension-samples)
+
+For questions, contact project maintainers or see CONTRIBUTING.md.

.github/instructions/wit-grammar.instructions.md

@@ -0,0 +1,39 @@
+---
+applyTo: "**/wit.tmLanguage.json"
+---
+
+# Instructions for WIT and Official Grammar
+
+## 1. What is WIT?
+- WIT (WebAssembly Interface Types) is a language and specification for describing interfaces between WebAssembly modules and their host environments.
+- It defines types, functions, resources, and modules in a language-agnostic way.
+
+## 2. Official Grammar
+- The official WIT grammar is defined in the `wit.tmLanguage.json` file and is used for syntax highlighting and parsing.
+- Refer to the [WIT specification](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md) for the authoritative grammar and language rules.
+- The grammar covers:
+  - Identifiers, keywords, and comments
+  - Type definitions (records, variants, enums, flags, etc.)
+  - Function and resource declarations
+  - Module and world definitions
+  - Versioning, namespace, and aliasing
+  - Markdown in doc comments
+
+## 3. Best Practices
+- Follow the official WIT grammar for all `.wit` files.
+- Use consistent formatting and indentation for readability.
+- Validate `.wit` files using available tools or language support in your editor.
+- Place WIT grammar and related files in the appropriate `syntaxes/` directory.
+- When updating the grammar, also update or add tests in `tests/grammar/` to cover new features, edge cases, or bug fixes.
+- If the WIT specification changes, update both the grammar and the tests to stay in sync.
+- For complex or non-obvious grammar rules, add or expand comments in `wit.tmLanguage.json` to help future maintainers.
+- Test new or changed grammar rules with both valid and invalid WIT syntax to ensure robust highlighting and error detection.
+
+## 4. Resources
+- [WIT Specification](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md)
+- [wit.tmLanguage.json](syntaxes/wit.tmLanguage.json) (project grammar file)
+- [WebAssembly Component Model](https://github.com/WebAssembly/component-model)
+- [Grammar Tests](tests/grammar/) (test suite for grammar validation)
+
+---
+For questions about WIT or its grammar, contact project maintainers or refer to the official specification.

.gitignore

@@ -70,7 +70,7 @@ typings/
 .cache
 
 # Typescript Output
-out/
+dist/
 
 # VSCode extension development
 .vscode-test/

.vscode/tasks.json

@@ -2,8 +2,8 @@
     "version": "2.0.0",
     "tasks": [
         {
-            "type": "npm",
             "label": "watch",
+            "type": "npm",
             "script": "watch",
             "problemMatcher": [],
             "presentation": {

esbuild.mjs

@@ -0,0 +1,59 @@
+// ESBuild configuration for building the VSCode extension (sample-based)
+// See: https://github.com/microsoft/vscode-extension-samples/blob/main/esbuild-sample/esbuild.js
+
+import * as esbuild from "esbuild";
+
+const production = process.argv.includes("--production");
+const watch = process.argv.includes("--watch");
+
+/**
+ * @type {import('esbuild').Plugin}
+ */
+const esbuildProblemMatcherPlugin = {
+    name: "esbuild-problem-matcher",
+    setup(build) {
+        build.onStart(() => {
+            console.log("[watch] build started");
+        });
+        build.onEnd((result) => {
+            result.errors.forEach(({ text, location }) => {
+                console.error(`✘ [ERROR] ${text}`);
+                if (location) {
+                    console.error(`    ${location.file}:${location.line}:${location.column}:`);
+                }
+            });
+            console.log("[watch] build finished");
+        });
+    },
+};
+
+async function main() {
+    const ctx = await esbuild.context({
+        entryPoints: [
+            "src/extension.ts"
+        ],
+        bundle: true,
+        format: "cjs",
+        minify: production,
+        sourcemap: !production,
+        sourcesContent: false,
+        platform: "node",
+        outfile: "dist/extension.js",
+        external: ["vscode"],
+        logLevel: "silent",
+        plugins: [
+            esbuildProblemMatcherPlugin,
+        ],
+    });
+    if (watch) {
+        await ctx.watch();
+    } else {
+        await ctx.rebuild();
+        await ctx.dispose();
+    }
+}
+
+main().catch(e => {
+    console.error(e);
+    process.exit(1);
+});

eslint.config.mjs

@@ -0,0 +1,22 @@
+import js from "@eslint/js";
+import globals from "globals";
+import tseslint from "typescript-eslint";
+import markdown from "@eslint/markdown";
+import css from "@eslint/css";
+import { defineConfig } from "eslint/config";
+
+export default defineConfig([
+    { files: ["**/*.{js,mjs,cjs,ts,mts,cts}"], plugins: { js }, extends: ["js/recommended"] },
+    { files: ["**/*.{js,mjs,cjs,ts,mts,cts}"], languageOptions: { globals: { ...globals.browser, ...globals.node } } },
+    tseslint.configs.recommended,
+    {
+        files: ["**/*.{ts,tsx,js,jsx}"],
+        rules: {
+            // Allow unused function parameters (disable rule)
+            '@typescript-eslint/no-unused-vars': 'off',
+            'quotes': ['error', 'double']
+        }
+    },
+    { files: ["**/*.md"], plugins: { markdown }, language: "markdown/gfm", extends: ["markdown/recommended"] },
+    { files: ["**/*.css"], plugins: { css }, language: "css/css", extends: ["css/recommended"] },
+]);