workspace-architect 1.3.0 → 1.5.0

package/assets/prompts/write-coding-standards-from-file.prompt.md

@@ -1,316 +0,0 @@
----
-mode: "agent"
-description: "Write a coding standards document for a project using the coding styles from the file(s) and/or folder(s) passed as arguments in the prompt."
-tools: ['createFile', 'editFiles', 'fetch', 'githubRepo', 'search', 'testFailure']
----
-
-# Write Coding Standards From File
-
-Use the existing syntax of the file(s) to establish the standards and style guides for the project. If more than one file or a folder is passed, loop through each file or files in the folder, appending the file's data to temporary memory or a file, then when complete use temporary data as a single instance; as if it were the file name to base the standards and style guideline on.
-
-## Rules and Configuration
-
-Below is a set of quasi-configuration `boolean` and `string[]` variables. Conditions for handling `true`, or other values for each variable are under the level two heading `## Variable and Parameter Configuration Conditions`. 
-
-Parameters for the prompt have a text definition. There is one required parameter **`${fileName}`**, and several optional parameters **`${folderName}`**, **`${instructions}`**, and any **`[configVariableAsParameter]`**.
-
-### Configuration Variables
-
-* addStandardsTest = false;
-* addToREADME = false;
-* addToREADMEInsertions = ["atBegin", "middle", "beforeEnd", "bestFitUsingContext"];
-  - Default to **beforeEnd**.
-* createNewFile = true;
-* fetchStyleURL = true;
-* findInconsistencies = true;
-* fixInconsistencies = true;
-* newFileName = ["CONTRIBUTING.md", "STYLE.md", "CODE_OF_CONDUCT.md", "CODING_STANDARDS.md", "DEVELOPING.md", "CONTRIBUTION_GUIDE.md", "GUIDELINES.md", "PROJECT_STANDARDS.md", "BEST_PRACTICES.md", "HACKING.md"];
-  - For each file in `${newFileName}`, if file does not exist, use that file name and `break`, else continue to next file name of `${newFileName}`.
-* outputSpecToPrompt = false;
-* useTemplate = "verbose"; // or "v"
-  - Possible values are `[["v", "verbose"], ["m", "minimal"], ["b", "best fit"], ["custom"]]`.
-  - Selects one of the two example templates at the bottom of prompt file under the level two heading `## Coding Standards Templates`, or use another composition that is a better fit.
-  - If **custom**, then apply per request.
-
-### Configuration Variables as Prompt Parameters
-
-If any of the variable names are passed to prompt as-is, or as a similar but clearly related text value, then override the default variable value with the value passed to prompt.
-
-### Prompt Parameters
-
-* **fileName** = The name of the file that will be analyzed in terms of: indentation, variable naming, commenting, conditional procedures, functional procedures, and other syntax related data for the coding language of the file.
-* folderName = The name of the folder that will be used to extract data from multiple files into one aggregated dataset that will be analyzed in terms of: indentation, variable naming, commenting, conditional procedures, functional procedures, and other syntax related data for the coding language of the files.
-* instructions = Additional instructions, rules, and procedures that will be provided for unique cases.
-* [configVariableAsParameter] = If passed will override the default state of the configuration variable. Example:
-  - useTemplate = If passed will override the configuration `${useTemplate}` default. Values are `[["v", "verbose"], ["m", "minimal"], ["b", "best fit"]]`.
-
-#### Required and Optional Parameters
-
-* **fileName** - required
-* folderName - *optional*
-* instructions - *optional*
-* [configVariableAsParameter] - *optional*
-
-## Variable and Parameter Configuration Conditions
-
-### `${fileName}.length > 1 || ${folderName} != undefined`
-
-* If true, toggle `${fixInconsistencies}` to false.
-
-### `${addToREADME} == true`
-
-* Insert the coding standards into the `README.md` instead of outputting to the prompt or creating a new file.
-* If true, toggle both `${createNewFile}` and `${outputSpecToPrompt}` to false.
-
-### `${addToREADMEInsertions} == "atBegin"`
-
-* If `${addToREADME}` is true, then insert the coding standards data at the **beginning** of the `README.md` file after the title.
-
-### `${addToREADMEInsertions} == "middle"`
-
-* If `${addToREADME}` is true, then insert the coding standards data at the **middle** of the `README.md` file, changing the standards title heading to match that of the `README.md` composition.
-
-### `${addToREADMEInsertions} == "beforeEnd"`
-
-* If `${addToREADME}` is true, then insert the coding standards data at the **end** of the `README.md` file, inserting a new line after the last character, then inserting the data on a new line.
-
-### `${addToREADMEInsertions} == "bestFitUsingContext"`
-
-* If `${addToREADME}` is true, then insert the coding standards data at the **best fitting line** of the `README.md` file in regards to the context of the `README.md` composition and flow of data.
-
-### `${addStandardsTest} == true`
-
-* Once the coding standards file is complete, write a test file to ensure the file or files passed to it adhere to the coding standards.
-
-### `${createNewFile} == true`
-
-* Create a new file using the value, or one of the possible values, from `${newFileName}`.
-* If true, toggle both `${outputSpecToPrompt}` and `${addToREADME}` to false.
-
-### `${fetchStyleURL} == true`
-
-* Additionally use the data fetched from the links nested under level three heading `### Fetch Links` as context for creating standards, specifications, and styling data for the new file, prompt, or `README.md`.
-* For each relevant item in `### Fetch Links`, run `#fetch ${item}`.
-
-### `${findInconsistencies} == true`
-
-* Evaluate syntax related to indentations, line-breaks, comments, conditional and function nesting, quotation wrappers i.e. `'` or `"` for strings, etc., and categorize.
-* For each category, make a count, and if one item does not match the majority of the count, then commit to temporary memory.
-* Depending on the status of `${fixInconsistencies}`, either edit and fix the low count categories to match the majority, or output to prompt inconsistencies stored in temporary memory.
-
-### `${fixInconsistencies} == true`
-
-* Edit and fix the low count categories of syntax data to match the majority of corresponding syntax data using inconsistencies stored in temporary memory.
-
-### `typeof ${newFileName} == "string"`
-
-* If specifically defined as a `string`, create a new file using the value from `${newFileName}`.
-
-### `typeof ${newFileName} != "string"`
-
-* If **NOT** specifically defined as a `string`, but instead an `object` or an array, create a new file using a value from `${newFileName}` by applying this rule:
-  - For each file name in `${newFileName}`, if file does not exist, use that file name and `break`, else continue to the next.
-
-### `${outputSpecToPrompt} == true`
-
-* Output the coding standards to the prompt instead of creating a file or adding to README.
-* If true, toggle both `${createNewFile}` and `${addToREADME}` to false.
-
-### `${useTemplate} == "v" || ${useTemplate} == "verbose"`
-
-* Use data under the level three heading `### "v", "verbose"` as guiding template when composing the data for coding standards.
-
-### `${useTemplate} == "m" || ${useTemplate} == "minimal"`
-
-* Use data under the level three heading `### "m", "minimal"` as guiding template when composing the data for coding standards.
-
-### `${useTemplate} == "b" || ${useTemplate} == "best"`
-
-* Use either the data under the level three heading `### "v", "verbose"` or `### "m", "minimal"`, depending on the data extracted from `${fileName}`, and use the best fit as guiding template when composing the data for coding standards.
-
-### `${useTemplate} == "custom" || ${useTemplate} == "<ANY_NAME>"`
-
-* Use the custom prompt, instructions, template, or other data passed as guiding template when composing the data for coding standards.
-
-## **if** `${fetchStyleURL} == true`
-
-Depending on the programming language, for each link in list below, run `#fetch (URL)`, if programming language is `${fileName} == [<Language> Style Guide]`.
-
-### Fetch Links
-
-- [C Style Guide](https://users.ece.cmu.edu/~eno/coding/CCodingStandard.html)
-- [C# Style Guide](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions)
-- [C++ Style Guide](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)
-- [Go Style Guide](https://github.com/golang-standards/project-layout)
-- [Java Style Guide](https://coderanch.com/wiki/718799/Style)
-- [AngularJS App Style Guide](https://github.com/mgechev/angularjs-style-guide)
-- [jQuery Style Guide](https://contribute.jquery.org/style-guide/js/)
-- [JavaScript Style Guide](https://www.w3schools.com/js/js_conventions.asp)
-- [JSON Style Guide](https://google.github.io/styleguide/jsoncstyleguide.xml)
-- [Kotlin Style Guide](https://kotlinlang.org/docs/coding-conventions.html)
-- [Markdown Style Guide](https://cirosantilli.com/markdown-style-guide/)
-- [Perl Style Guide](https://perldoc.perl.org/perlstyle)
-- [PHP Style Guide](https://phptherightway.com/)
-- [Python Style Guide](https://peps.python.org/pep-0008/)
-- [Ruby Style Guide](https://rubystyle.guide/)
-- [Rust Style Guide](https://github.com/rust-lang/rust/tree/HEAD/src/doc/style-guide/src)
-- [Swift Style Guide](https://www.swift.org/documentation/api-design-guidelines/)
-- [TypeScript Style Guide](https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html)
-- [Visual Basic Style Guide](https://en.wikibooks.org/wiki/Visual_Basic/Coding_Standards)
-- [Shell Script Style Guide](https://google.github.io/styleguide/shellguide.html)
-- [Git Usage Style Guide](https://github.com/agis/git-style-guide)
-- [PowerShell Style Guide](https://github.com/PoshCode/PowerShellPracticeAndStyle)
-- [CSS](https://cssguidelin.es/)
-- [Sass Style Guide](https://sass-guidelin.es/)
-- [HTML Style Guide](https://github.com/marcobiedermann/html-style-guide)
-- [Linux kernel Style Guide](https://www.kernel.org/doc/html/latest/process/coding-style.html)
-- [Node.js Style Guide](https://github.com/felixge/node-style-guide)
-- [SQL Style Guide](https://www.sqlstyle.guide/)
-- [Angular Style Guide](https://angular.dev/style-guide)
-- [Vue Style Guide](https://vuejs.org/style-guide/rules-strongly-recommended.html)
-- [Django Style Guide](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/)
-
-## Coding Standards Templates
-
-### `"m", "minimal"`
-
-```text
-    ```markdown
-    ## 1. Introduction
-    *   **Purpose:** Briefly explain why the coding standards are being established (e.g., to improve code quality, maintainability, and team collaboration).
-    *   **Scope:** Define which languages, projects, or modules this specification applies to.
-
-    ## 2. Naming Conventions
-    *   **Variables:** `camelCase`
-    *   **Functions/Methods:** `PascalCase` or `camelCase`.
-    *   **Classes/Structs:** `PascalCase`.
-    *   **Constants:** `UPPER_SNAKE_CASE`.
-
-    ## 3. Formatting and Style
-    *   **Indentation:** Use 4 spaces per indent (or tabs).
-    *   **Line Length:** Limit lines to a maximum of 80 or 120 characters.
-    *   **Braces:** Use the "K&R" style (opening brace on the same line) or the "Allman" style (opening brace on a new line).
-    *   **Blank Lines:** Specify how many blank lines to use for separating logical blocks of code.
-
-    ## 4. Commenting
-    *   **Docstrings/Function Comments:** Describe the function's purpose, parameters, and return values.
-    *   **Inline Comments:** Explain complex or non-obvious logic.
-    *   **File Headers:** Specify what information should be included in a file header, such as author, date, and file description.
-
-    ## 5. Error Handling
-    *   **General:** How to handle and log errors.
-    *   **Specifics:** Which exception types to use, and what information to include in error messages.
-
-    ## 6. Best Practices and Anti-Patterns
-    *   **General:** List common anti-patterns to avoid (e.g., global variables, magic numbers).
-    *   **Language-specific:** Specific recommendations based on the project's programming language.
-
-    ## 7. Examples
-    *   Provide a small code example demonstrating the correct application of the rules.
-    *   Provide a small code example of an incorrect implementation and how to fix it.
-
-    ## 8. Contribution and Enforcement
-    *   Explain how the standards are to be enforced (e.g., via code reviews).
-    *   Provide a guide for contributing to the standards document itself.
-    ```
-```
-
-### `"v", verbose"`
-
-```text
-    ```markdown
-
-    # Style Guide
-
-    This document defines the style and conventions used in this project.  
-    All contributions should follow these rules unless otherwise noted.
-
-    ## 1. General Code Style
-
-    - Favor clarity over brevity.
-    - Keep functions and methods small and focused.
-    - Avoid repeating logic; prefer shared helpers/utilities.
-    - Remove unused variables, imports, code paths, and files.
-
-    ## 2. Naming Conventions
-
-    Use descriptive names. Avoid abbreviations unless well-known.
-
-    | Item            | Convention           | Example            |
-    |-----------------|----------------------|--------------------|
-    | Variables       | `lower_snake_case`   | `buffer_size`      |
-    | Functions       | `lower_snake_case()` | `read_file()`      |
-    | Constants       | `UPPER_SNAKE_CASE`   | `MAX_RETRIES`      |
-    | Types/Structs   | `PascalCase`         | `FileHeader`       |
-    | File Names      | `lower_snake_case`   | `file_reader.c`    |
-
-    ## 3. Formatting Rules
-
-    - Indentation: **4 spaces**
-    - Line length: **max 100 characters**
-    - Encoding: **UTF-8**, no BOM
-    - End files with a newline
-
-    ### Braces (example in C, adjust for your language)
-
-        ```c
-        if (condition) {
-            do_something();
-        } else {
-            do_something_else();
-        }
-        ```
-
-    ### Spacing
-
-    - One space after keywords: `if (x)`, not `if(x)`
-    - One blank line between top-level functions
-
-    ## 4. Comments & Documentation
-
-    - Explain *why*, not *what*, unless intent is unclear.
-    - Keep comments up-to-date as code changes.
-    - Public functions should include a short description of purpose and parameters.
-
-    Recommended tags:
-
-        ```text
-        TODO: follow-up work
-        FIXME: known incorrect behavior
-        NOTE: non-obvious design decision
-        ```
-
-    ## 5. Error Handling
-
-    - Handle error conditions explicitly.
-    - Avoid silent failures; either return errors or log them appropriately.
-    - Clean up resources (files, memory, handles) before returning on failure.
-
-    ## 6. Commit & Review Practices
-
-    ### Commits
-    - One logical change per commit.
-    - Write clear commit messages:
-
-        ```text
-        Short summary (max ~50 chars)
-        Optional longer explanation of context and rationale.
-        ```
-
-    ### Reviews
-    - Keep pull requests reasonably small.
-    - Be respectful and constructive in review discussions.
-    - Address requested changes or explain if you disagree.
-
-    ## 7. Tests
-
-    - Write tests for new functionality.
-    - Tests should be deterministic (no randomness without seeding).
-    - Prefer readable test cases over complex test abstraction.
-
-    ## 8. Changes to This Guide
-
-    Style evolves.  
-    Propose improvements by opening an issue or sending a patch updating this document.
-    ```
-```

package/scripts/sync.js

@@ -1,99 +0,0 @@
-import fs from 'fs';
-import path from 'path';
-import { fileURLToPath } from 'url';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = path.dirname(__filename);
-
-// Load .env manually
-const envPath = path.join(__dirname, '../.env');
-if (fs.existsSync(envPath)) {
-  const envConfig = fs.readFileSync(envPath, 'utf8');
-  envConfig.split('\n').forEach(line => {
-    const [key, value] = line.split('=');
-    if (key && value) {
-      process.env[key.trim()] = value.trim();
-    }
-  });
-}
-
-const GITHUB_TOKEN = process.env.GITHUB_TOKEN;
-const REPO_OWNER = 'github';
-const REPO_NAME = 'awesome-copilot';
-const BASE_API_URL = `https://api.github.com/repos/${REPO_OWNER}/${REPO_NAME}/contents`;
-
-const MAPPINGS = [
-  { remote: 'chatmodes', local: 'assets/chatmodes' },
-  { remote: 'instructions', local: 'assets/instructions' },
-  { remote: 'prompts', local: 'assets/prompts' }
-];
-
-const FILES_TO_DELETE = [
-  'basic-setup.md',
-  'assets/instructions/basic-setup.md'
-];
-
-async function fetchGitHubContent(path) {
-  const url = `${BASE_API_URL}/${path}`;
-  const headers = {
-    'User-Agent': 'node.js',
-    'Accept': 'application/vnd.github.v3+json'
-  };
-  
-  if (GITHUB_TOKEN) {
-    headers['Authorization'] = `token ${GITHUB_TOKEN}`;
-  }
-
-  const response = await fetch(url, { headers });
-  if (!response.ok) {
-    throw new Error(`Failed to fetch ${url}: ${response.statusText}`);
-  }
-  return response.json();
-}
-
-async function downloadFile(downloadUrl, localPath) {
-  const response = await fetch(downloadUrl);
-  if (!response.ok) {
-    throw new Error(`Failed to download ${downloadUrl}: ${response.statusText}`);
-  }
-  const content = await response.text();
-  const dir = path.dirname(localPath);
-  if (!fs.existsSync(dir)) {
-    fs.mkdirSync(dir, { recursive: true });
-  }
-  fs.writeFileSync(localPath, content);
-  console.log(`Downloaded: ${localPath}`);
-}
-
-async function sync() {
-  console.log('Starting sync...');
-  
-  // Delete legacy files
-  for (const file of FILES_TO_DELETE) {
-    const filePath = path.join(__dirname, '..', file);
-    if (fs.existsSync(filePath)) {
-      fs.unlinkSync(filePath);
-      console.log(`Deleted: ${file}`);
-    }
-  }
-
-  // Sync folders
-  for (const mapping of MAPPINGS) {
-    console.log(`Syncing ${mapping.remote} to ${mapping.local}...`);
-    try {
-      const items = await fetchGitHubContent(mapping.remote);
-      
-      for (const item of items) {
-        if (item.type === 'file') {
-          const localFilePath = path.join(__dirname, '..', mapping.local, item.name);
-          await downloadFile(item.download_url, localFilePath);
-        }
-      }
-    } catch (error) {
-      console.error(`Error syncing ${mapping.remote}:`, error.message);
-    }
-  }
-  console.log('Sync complete!');
-}
-
-sync();

package/verdaccio/config.yaml

@@ -1,202 +0,0 @@
-#
-# This is the default configuration file. It allows all users to do anything,
-# please read carefully the documentation and best practices to
-# improve security.
-#
-# Look here for more config file examples:
-# https://github.com/verdaccio/verdaccio/tree/5.x/conf
-#
-# Read about the best practices
-# https://verdaccio.org/docs/best
-
-# path to a directory with all packages
-storage: ./storage
-# path to a directory with plugins to include
-plugins: ./plugins
-
-# https://verdaccio.org/docs/webui
-web:
-  title: Verdaccio
-  # comment out to disable gravatar support
-  # gravatar: false
-  # by default packages are ordercer ascendant (asc|desc)
-  # sort_packages: asc
-  # convert your UI to the dark side
-  # darkMode: true
-  # html_cache: true
-  # by default all features are displayed
-  # login: true
-  # showInfo: true
-  # showSettings: true
-  # In combination with darkMode you can force specific theme
-  # showThemeSwitch: true
-  # showFooter: true
-  # showSearch: true
-  # showRaw: true
-  # showDownloadTarball: true
-  #  HTML tags injected after manifest <scripts/>
-  # scriptsBodyAfter:
-  #    - '<script type="text/javascript" src="https://my.company.com/customJS.min.js"></script>'
-  #  HTML tags injected before ends </head>
-  #  metaScripts:
-  #    - '<script type="text/javascript" src="https://code.jquery.com/jquery-3.5.1.slim.min.js"></script>'
-  #    - '<script type="text/javascript" src="https://browser.sentry-cdn.com/5.15.5/bundle.min.js"></script>'
-  #    - '<meta name="robots" content="noindex" />'
-  #  HTML tags injected first child at <body/>
-  #  bodyBefore:
-  #    - '<div id="myId">html before webpack scripts</div>'
-  #  Public path for template manifest scripts (only manifest)
-  #  publicPath: http://somedomain.org/
-
-# https://verdaccio.org/docs/configuration#authentication
-auth:
-  htpasswd:
-    file: ./htpasswd
-    # Maximum amount of users allowed to register, defaults to "+inf".
-    # You can set this to -1 to disable registration.
-    # max_users: 1000
-    # Hash algorithm, possible options are: "bcrypt", "md5", "sha1", "crypt".
-    # algorithm: bcrypt # by default is crypt, but is recommended use bcrypt for new installations
-    # Rounds number for "bcrypt", will be ignored for other algorithms.
-    # rounds: 10
-
-# https://verdaccio.org/docs/configuration#uplinks
-# a list of other known repositories we can talk to
-uplinks:
-  npmjs:
-    url: https://registry.npmjs.org/
-
-# Learn how to protect your packages
-# https://verdaccio.org/docs/protect-your-dependencies/
-# https://verdaccio.org/docs/configuration#packages
-packages:
-  '@*/*':
-    # scoped packages
-    access: $all
-    publish: $authenticated
-    unpublish: $authenticated
-    proxy: npmjs
-
-  '**':
-    # allow all users (including non-authenticated users) to read and
-    # publish all packages
-    #
-    # you can specify usernames/groupnames (depending on your auth plugin)
-    # and three keywords: "$all", "$anonymous", "$authenticated"
-    access: $all
-
-    # allow all known users to publish/publish packages
-    # (anyone can register by default, remember?)
-    publish: $all
-    unpublish: $all
-
-    # if package is not available locally, proxy requests to 'npmjs' registry
-    proxy: npmjs
-
-# To improve your security configuration and  avoid dependency confusion
-# consider removing the proxy property for private packages
-# https://verdaccio.org/docs/best#remove-proxy-to-increase-security-at-private-packages
-
-# https://verdaccio.org/docs/configuration#server
-# You can specify HTTP/1.1 server keep alive timeout in seconds for incoming connections.
-# A value of 0 makes the http server behave similarly to Node.js versions prior to 8.0.0, which did not have a keep-alive timeout.
-# WORKAROUND: Through given configuration you can workaround following issue https://github.com/verdaccio/verdaccio/issues/301. Set to 0 in case 60 is not enough.
-server:
-  keepAliveTimeout: 60
-  # Allow `req.ip` to resolve properly when Verdaccio is behind a proxy or load-balancer
-  # See: https://expressjs.com/en/guide/behind-proxies.html
-  # trustProxy: '127.0.0.1'
-
-# https://verdaccio.org/docs/configuration#offline-publish
-# publish:
-#   allow_offline: false
-
-# https://verdaccio.org/docs/configuration#url-prefix
-# url_prefix: /verdaccio/
-# VERDACCIO_PUBLIC_URL='https://somedomain.org';
-# url_prefix: '/my_prefix'
-# // url -> https://somedomain.org/my_prefix/
-# VERDACCIO_PUBLIC_URL='https://somedomain.org';
-# url_prefix: '/'
-# // url -> https://somedomain.org/
-# VERDACCIO_PUBLIC_URL='https://somedomain.org/first_prefix';
-# url_prefix: '/second_prefix'
-# // url -> https://somedomain.org/second_prefix/'
-
-# https://verdaccio.org/docs/configuration#security
-# security:
-#   api:
-#     legacy: true
-#     # recomended set to true for older installations
-#     migrateToSecureLegacySignature: true
-#     jwt:
-#       sign:
-#         expiresIn: 29d
-#       verify:
-#         someProp: [value]
-#    web:
-#      sign:
-#        expiresIn: 1h # 1 hour by default
-#      verify:
-#         someProp: [value]
-
-# https://verdaccio.org/docs/configuration#user-rate-limit
-# userRateLimit:
-#   windowMs: 50000
-#   max: 1000
-
-# https://verdaccio.org/docs/configuration#max-body-size
-# max_body_size: 10mb
-
-# https://verdaccio.org/docs/configuration#listen-port
-listen: 0.0.0.0:4873
-# listen:
-# - localhost:4873            # default value
-# - http://localhost:4873     # same thing
-# - 0.0.0.0:4873              # listen on all addresses (INADDR_ANY)
-# - https://example.org:4873  # if you want to use https
-# - "[::1]:4873"                # ipv6
-# - unix:/tmp/verdaccio.sock    # unix socket
-
-# The HTTPS configuration is useful if you do not consider use a HTTP Proxy
-# https://verdaccio.org/docs/configuration#https
-# https:
-#   key: ./path/verdaccio-key.pem
-#   cert: ./path/verdaccio-cert.pem
-#   ca: ./path/verdaccio-csr.pem
-
-# https://verdaccio.org/docs/configuration#proxy
-# http_proxy: http://something.local/
-# https_proxy: https://something.local/
-
-# https://verdaccio.org/docs/configuration#notifications
-# notify:
-#   method: POST
-#   headers: [{ "Content-Type": "application/json" }]
-#   endpoint: https://usagge.hipchat.com/v2/room/3729485/notification?auth_token=mySecretToken
-#   content: '{"color":"green","message":"New package published: * {{ name }}*","notify":true,"message_format":"text"}'
-
-middlewares:
-  audit:
-    enabled: true
-
-# https://verdaccio.org/docs/logger
-# log settings
-log: { type: stdout, format: pretty, level: http }
-#experiments:
-#  # support for npm token command
-#  token: false
-#  # disable writing body size to logs, read more on ticket 1912
-#  bytesin_off: false
-#  # enable tarball URL redirect for hosting tarball with a different server, the tarball_url_redirect can be a template string
-#  tarball_url_redirect: 'https://mycdn.com/verdaccio/${packageName}/${filename}'
-#  # the tarball_url_redirect can be a function, takes packageName and filename and returns the url, when working with a js configuration file
-#  tarball_url_redirect(packageName, filename) {
-#    const signedUrl = // generate a signed url
-#    return signedUrl;
-#  }
-
-# translate your registry, api i18n not available yet
-# i18n:
-# list of the available translations https://github.com/verdaccio/verdaccio/blob/master/packages/plugins/ui-theme/src/i18n/ABOUT_TRANSLATIONS.md
-#   web: en-US