ai-hero-cli 0.0.3 → 0.0.5

package/docs/tsconfig/noUncheckedIndexedAccess.md

@@ -0,0 +1,53 @@
+---
+display: 'No Unchecked Indexed Access'
+oneline: 'Add `undefined` to a type when accessed using an index.'
+---
+
+TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.
+
+```ts twoslash
+interface EnvironmentVars {
+  NAME: string;
+  OS: string;
+
+  // Unknown properties are covered by this index signature.
+  [propName: string]: string;
+}
+
+declare const env: EnvironmentVars;
+
+// Declared as existing
+const sysName = env.NAME;
+const os = env.OS;
+//    ^?
+
+// Not declared, but because of the index
+// signature, then it is considered a string
+const nodeEnv = env.NODE_ENV;
+//    ^?
+```
+
+Turning on `noUncheckedIndexedAccess` will add `undefined` to any un-declared field in the type.
+
+```ts twoslash
+interface EnvironmentVars {
+  NAME: string;
+  OS: string;
+
+  // Unknown properties are covered by this index signature.
+  [propName: string]: string;
+}
+// @noUncheckedIndexedAccess
+// ---cut---
+declare const env: EnvironmentVars;
+
+// Declared as existing
+const sysName = env.NAME;
+const os = env.OS;
+//    ^?
+
+// Not declared, but because of the index
+// signature, then it is considered a string
+const nodeEnv = env.NODE_ENV;
+//    ^?
+```

package/docs/tsconfig/noUncheckedSideEffectImports.md

@@ -0,0 +1,52 @@
+---
+display: 'noUncheckedSideEffectImports'
+oneline: 'Check side effect imports.'
+---
+
+In JavaScript it's possible to `import` a module without actually importing any values from it.
+
+```ts
+import 'some-module';
+```
+
+These imports are often called _side effect imports_ because the only useful behavior they can provide is by executing some side effect (like registering a global variable, or adding a polyfill to a prototype).
+
+By default, TypeScript will not check these imports for validity. If the import resolves to a valid source file, TypeScript will load and check the file.
+If no source file is found, TypeScript will silently ignore the import.
+
+This is surprising behavior, but it partially stems from modeling patterns in the JavaScript ecosystem.
+For example, this syntax has also been used with special loaders in bundlers to load CSS or other assets.
+Your bundler might be configured in such a way where you can include specific `.css` files by writing something like the following:
+
+```tsx
+import './button-component.css';
+
+export function Button() {
+  // ...
+}
+```
+
+Still, this masks potential typos on side effect imports.
+
+When `--noUncheckedSideEffectImports` is enabled, TypeScript will error if it can't find a source file for a side effect import.
+
+```ts
+import 'oops-this-module-does-not-exist';
+//     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+// error: Cannot find module 'oops-this-module-does-not-exist' or its corresponding
+//        type declarations.
+```
+
+When enabling this option, some working code may now receive an error, like in the CSS example above.
+To work around this, users who want to just write side effect `import`s for assets might be better served by writing what's called an _ambient module declaration_ with a wildcard specifier.
+It would go in a global file and look something like the following:
+
+```ts
+// ./src/globals.d.ts
+
+// Recognize all CSS files as module imports.
+declare module '*.css' {}
+```
+
+In fact, you might already have a file like this in your project!
+For example, running something like `vite init` might create a similar `vite-env.d.ts`.

package/docs/tsconfig/noUnusedLocals.md

@@ -0,0 +1,15 @@
+---
+display: 'No Unused Locals'
+oneline: "Enable error reporting when local variables aren't read."
+---
+
+Report errors on unused local variables.
+
+```ts twoslash
+// @noUnusedLocals
+// @errors: 6133
+const createKeyboard = (modelID: number) => {
+  const defaultModelID = 23;
+  return { type: 'keyboard', modelID };
+};
+```

package/docs/tsconfig/noUnusedParameters.md

@@ -0,0 +1,15 @@
+---
+display: 'No Unused Parameters'
+oneline: "Raise an error when a function parameter isn't read."
+---
+
+Report errors on unused parameters in functions.
+
+```ts twoslash
+// @noUnusedParameters
+// @errors: 6133
+const createDefaultKeyboard = (modelID: number) => {
+  const defaultModelID = 23;
+  return { type: 'keyboard', modelID: defaultModelID };
+};
+```

package/docs/tsconfig/out.md

@@ -0,0 +1,9 @@
+---
+display: 'Out'
+oneline: 'Deprecated setting. Use [`outFile`](#outFile) instead.'
+---
+
+Use [`outFile`](#outFile) instead.
+
+The `out` option computes the final file location in a way that is not predictable or consistent.
+This option is retained for backward compatibility only and is deprecated.

package/docs/tsconfig/outDir.md

@@ -0,0 +1,39 @@
+---
+display: 'Out Dir'
+oneline: 'Specify an output folder for all emitted files.'
+---
+
+If specified, `.js` (as well as `.d.ts`, `.js.map`, etc.) files will be emitted into this directory.
+The directory structure of the original source files is preserved; see [`rootDir`](#rootDir) if the computed root is not what you intended.
+
+If not specified, `.js` files will be emitted in the same directory as the `.ts` files they were generated from:
+
+```sh
+$ tsc
+
+example
+├── index.js
+└── index.ts
+```
+
+With a `tsconfig.json` like this:
+
+```json tsconfig
+{
+  "compilerOptions": {
+    "outDir": "dist"
+  }
+}
+```
+
+Running `tsc` with these settings moves the files into the specified `dist` folder:
+
+```sh
+$ tsc
+
+example
+├── dist
+│   └── index.js
+├── index.ts
+└── tsconfig.json
+```

package/docs/tsconfig/outFile.md

@@ -0,0 +1,11 @@
+---
+display: 'Out File'
+oneline: 'Specify a file that bundles all outputs into one JavaScript file. If [`declaration`](#declaration) is true, also designates a file that bundles all .d.ts output.'
+---
+
+If specified, all _global_ (non-module) files will be concatenated into the single output file specified.
+
+If `module` is `system` or `amd`, all module files will also be concatenated into this file after all global content.
+
+Note: `outFile` cannot be used unless `module` is `None`, `System`, or `AMD`.
+This option _cannot_ be used to bundle CommonJS or ES6 modules.

package/docs/tsconfig/paths.md

@@ -0,0 +1,39 @@
+---
+display: 'Paths'
+oneline: 'Specify a set of entries that re-map imports to additional lookup locations.'
+---
+
+A series of entries which re-map imports to lookup locations relative to the [`baseUrl`](#baseUrl) if set, or to the tsconfig file itself otherwise. There is a larger coverage of `paths` in [the `moduleResolution` reference page](/docs/handbook/modules/reference.html#paths).
+
+`paths` lets you declare how TypeScript should resolve an import in your `require`/`import`s.
+
+```json tsconfig
+{
+  "compilerOptions": {
+    "paths": {
+      "jquery": ["./vendor/jquery/dist/jquery"]
+    }
+  }
+}
+```
+
+This would allow you to be able to write `import "jquery"`, and get all of the correct typing locally.
+
+```json tsconfig
+{
+  "compilerOptions": {
+    "paths": {
+      "app/*": ["./src/app/*"],
+      "config/*": ["./src/app/_config/*"],
+      "environment/*": ["./src/environments/*"],
+      "shared/*": ["./src/app/_shared/*"],
+      "helpers/*": ["./src/helpers/*"],
+      "tests/*": ["./src/tests/*"]
+    }
+  }
+}
+```
+
+In this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.
+
+Note that this feature does not change how import paths are emitted by `tsc`, so `paths` should only be used to inform TypeScript that another tool has this mapping and will use it at runtime or when bundling.

package/docs/tsconfig/plugins.md

@@ -0,0 +1,17 @@
+---
+display: 'Plugins'
+oneline: 'Specify a list of language service plugins to include.'
+---
+
+List of language service plugins to run inside the editor.
+
+Language service plugins are a way to provide additional information to a user based on existing TypeScript files. They can enhance existing messages between TypeScript and an editor, or to provide their own error messages.
+
+For example:
+
+- [ts-sql-plugin](https://github.com/xialvjun/ts-sql-plugin#readme) — Adds SQL linting with a template strings SQL builder.
+- [typescript-styled-plugin](https://github.com/Microsoft/typescript-styled-plugin) — Provides CSS linting inside template strings .
+- [typescript-eslint-language-service](https://github.com/Quramy/typescript-eslint-language-service) — Provides eslint error messaging and fix-its inside the compiler's output.
+- [ts-graphql-plugin](https://github.com/Quramy/ts-graphql-plugin) — Provides validation and auto-completion inside GraphQL query template strings.
+
+VS Code has the ability for a extension to [automatically include language service plugins](https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins), and so you may have some running in your editor without needing to define them in your `tsconfig.json`.

package/docs/tsconfig/preserveConstEnums.md

@@ -0,0 +1,58 @@
+---
+display: 'Preserve Const Enums'
+oneline: 'Disable erasing `const enum` declarations in generated code.'
+---
+
+Do not erase `const enum` declarations in generated code. `const enum`s provide a way to reduce the overall memory footprint
+of your application at runtime by emitting the enum value instead of a reference.
+
+For example with this TypeScript:
+
+```ts twoslash
+const enum Album {
+  JimmyEatWorldFutures = 1,
+  TubRingZooHypothesis = 2,
+  DogFashionDiscoAdultery = 3,
+}
+
+const selectedAlbum = Album.JimmyEatWorldFutures;
+if (selectedAlbum === Album.JimmyEatWorldFutures) {
+  console.log('That is a great choice.');
+}
+```
+
+The default `const enum` behavior is to convert any `Album.Something` to the corresponding number literal, and to remove a reference
+to the enum from the JavaScript completely.
+
+```ts twoslash
+// @showEmit
+const enum Album {
+  JimmyEatWorldFutures = 1,
+  TubRingZooHypothesis = 2,
+  DogFashionDiscoAdultery = 3,
+}
+
+const selectedAlbum = Album.JimmyEatWorldFutures;
+if (selectedAlbum === Album.JimmyEatWorldFutures) {
+  console.log('That is a great choice.');
+}
+```
+
+With `preserveConstEnums` set to `true`, the `enum` exists at runtime and the numbers are still emitted.
+
+```ts twoslash
+// @preserveConstEnums: true
+// @showEmit
+const enum Album {
+  JimmyEatWorldFutures = 1,
+  TubRingZooHypothesis = 2,
+  DogFashionDiscoAdultery = 3,
+}
+
+const selectedAlbum = Album.JimmyEatWorldFutures;
+if (selectedAlbum === Album.JimmyEatWorldFutures) {
+  console.log('That is a great choice.');
+}
+```
+
+This essentially makes such `const enums` a source-code feature only, with no runtime traces.

package/docs/tsconfig/preserveSymlinks.md

@@ -0,0 +1,10 @@
+---
+display: 'Preserve Symlinks'
+oneline: 'Disable resolving symlinks to their realpath. This correlates to the same flag in node.'
+---
+
+This is to reflect the same flag in Node.js; which does not resolve the real path of symlinks.
+
+This flag also exhibits the opposite behavior to Webpack’s `resolve.symlinks` option (i.e. setting TypeScript’s `preserveSymlinks` to true parallels setting Webpack’s `resolve.symlinks` to false, and vice-versa).
+
+With this enabled, references to modules and packages (e.g. `import`s and `/// <reference type="..." />` directives) are all resolved relative to the location of the symbolic link file, rather than relative to the path that the symbolic link resolves to.

package/docs/tsconfig/preserveValueImports.md

@@ -0,0 +1,18 @@
+---
+display: 'Preserve Value Imports'
+oneline: 'Preserve unused imported values in the JavaScript output that would otherwise be removed.'
+---
+
+Deprecated in favor of [`verbatimModuleSyntax`](#verbatimModuleSyntax).
+
+There are some cases where TypeScript can't detect that you're using an import. For example, take the following code:
+
+```ts
+import { Animal } from './animal.js';
+
+eval('console.log(new Animal().isDangerous())');
+```
+
+or code using 'Compiles to HTML' languages like Svelte or Vue. `preserveValueImports` will prevent TypeScript from removing the import, even if it appears unused.
+
+When combined with [`isolatedModules`](#isolatedModules): imported types _must_ be marked as type-only because compilers that process single files at a time have no way of knowing whether imports are values that appear unused, or a type that must be removed in order to avoid a runtime crash.

package/docs/tsconfig/preserveWatchOutput.md

@@ -0,0 +1,6 @@
+---
+display: 'Preserve Watch Output'
+oneline: 'Disable wiping the console in watch mode.'
+---
+
+Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.

package/docs/tsconfig/pretty.md

@@ -0,0 +1,7 @@
+---
+display: 'Pretty'
+oneline: "Enable color and formatting in TypeScript's output to make compiler errors easier to read."
+---
+
+Stylize errors and messages using color and context, this is on by default — offers you a chance to have less terse,
+single colored messages from the compiler.

package/docs/tsconfig/reactNamespace.md

@@ -0,0 +1,6 @@
+---
+display: 'React Namespace'
+oneline: 'Specify the object invoked for `createElement`. This only applies when targeting `react` JSX emit.'
+---
+
+Use [`jsxFactory`](#jsxFactory) instead. Specify the object invoked for `createElement` when targeting `react` for TSX files.

package/docs/tsconfig/references.md

@@ -0,0 +1,9 @@
+---
+display: 'References'
+oneline: 'Specify an array of objects that specify paths for projects. Used in project references.'
+---
+
+Project references are a way to structure your TypeScript programs into smaller pieces.
+Using Project References can greatly improve build and editor interaction times, enforce logical separation between components, and organize your code in new and improved ways.
+
+You can read more about how references works in the [Project References](/docs/handbook/project-references.html) section of the handbook

package/docs/tsconfig/removeComments.md

@@ -0,0 +1,33 @@
+---
+display: 'Remove Comments'
+oneline: 'Disable emitting comments.'
+---
+
+Strips all comments from TypeScript files when converting into JavaScript. Defaults to `false`.
+
+For example, this is a TypeScript file which has a JSDoc comment:
+
+```ts
+/** The translation of 'Hello world' into Portuguese */
+export const helloWorldPTBR = 'Olá Mundo';
+```
+
+When `removeComments` is set to `true`:
+
+```ts twoslash
+// @showEmit
+// @removeComments: true
+/** The translation of 'Hello world' into Portuguese */
+export const helloWorldPTBR = 'Olá Mundo';
+```
+
+Without setting `removeComments` or having it as `false`:
+
+```ts twoslash
+// @showEmit
+// @removeComments: false
+/** The translation of 'Hello world' into Portuguese */
+export const helloWorldPTBR = 'Olá Mundo';
+```
+
+This means that your comments will show up in the JavaScript code.

package/docs/tsconfig/resolveJsonModule.md

@@ -0,0 +1,44 @@
+---
+display: 'Resolve JSON Module'
+oneline: 'Enable importing .json files.'
+---
+
+Allows importing modules with a `.json` extension, which is a common practice in node projects. This includes
+generating a type for the `import` based on the static JSON shape.
+
+TypeScript does not support resolving JSON files by default:
+
+```ts twoslash
+// @errors: 2732
+// @filename: settings.json
+{
+    "repo": "TypeScript",
+    "dry": false,
+    "debug": false
+}
+// @filename: index.ts
+import settings from "./settings.json";
+
+settings.debug === true;
+settings.dry === 2;
+```
+
+Enabling the option allows importing JSON, and validating the types in that JSON file.
+
+```ts twoslash
+// @errors: 2367
+// @resolveJsonModule
+// @module: commonjs
+// @moduleResolution: node
+// @filename: settings.json
+{
+    "repo": "TypeScript",
+    "dry": false,
+    "debug": false
+}
+// @filename: index.ts
+import settings from "./settings.json";
+
+settings.debug === true;
+settings.dry === 2;
+```

package/docs/tsconfig/resolvePackageJsonExports.md

@@ -0,0 +1,8 @@
+---
+display: 'Resolve package.json Exports'
+oneline: "Use the package.json 'exports' field when resolving package imports."
+---
+
+`--resolvePackageJsonExports` forces TypeScript to consult [the `exports` field of `package.json` files](https://nodejs.org/api/packages.html#exports) if it ever reads from a package in `node_modules`.
+
+This option defaults to `true` under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](#moduleResolution).

package/docs/tsconfig/resolvePackageJsonImports.md

@@ -0,0 +1,8 @@
+---
+display: 'Resolve package.json Imports'
+oneline: "Use the package.json 'imports' field when resolving imports."
+---
+
+`--resolvePackageJsonImports` forces TypeScript to consult [the `imports` field of `package.json` files](https://nodejs.org/api/packages.html#imports) when performing a lookup that starts with `#` from a file whose ancestor directory contains a `package.json`.
+
+This option defaults to `true` under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](#moduleResolution).

package/docs/tsconfig/rewriteRelativeImportExtensions.md

@@ -0,0 +1,8 @@
+---
+display: 'rewriteRelativeImportExtensions'
+oneline: 'Rewrite `.ts`, `.tsx`, `.mts`, and `.cts` file extensions in relative import paths to their JavaScript equivalent in output files.'
+---
+
+Rewrite `.ts`, `.tsx`, `.mts`, and `.cts` file extensions in relative import paths to their JavaScript equivalent in output files.
+
+For more information, see the [TypeScript 5.7 release notes](/docs/handbook/release-notes/typescript-5-7.html#path-rewriting-for-relative-paths).

package/docs/tsconfig/rootDir.md

@@ -0,0 +1,66 @@
+---
+display: 'Root Dir'
+oneline: 'Specify the root folder within your source files.'
+---
+
+**Default**: The longest common path of all non-declaration input files. If [`composite`](#composite) is set, the default is instead the directory containing the `tsconfig.json` file.
+
+When TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.
+
+For example, let's say you have some input files:
+
+```
+MyProj
+├── tsconfig.json
+├── core
+│   ├── a.ts
+│   ├── b.ts
+│   ├── sub
+│   │   ├── c.ts
+├── types.d.ts
+```
+
+The inferred value for `rootDir` is the longest common path of all non-declaration input files, which in this case is `core/`.
+
+If your [`outDir`](#outDir) was `dist`, TypeScript would write this tree:
+
+```
+MyProj
+├── dist
+│   ├── a.js
+│   ├── b.js
+│   ├── sub
+│   │   ├── c.js
+```
+
+However, you may have intended for `core` to be part of the output directory structure.
+By setting `rootDir: "."` in `tsconfig.json`, TypeScript would write this tree:
+
+```
+MyProj
+├── dist
+│   ├── core
+│   │   ├── a.js
+│   │   ├── b.js
+│   │   ├── sub
+│   │   │   ├── c.js
+```
+
+Importantly, `rootDir` **does not affect which files become part of the compilation**.
+It has no interaction with the [`include`](#include), [`exclude`](#exclude), or [`files`](#files) `tsconfig.json` settings.
+
+Note that TypeScript will never write an output file to a directory outside of [`outDir`](#outDir), and will never skip emitting a file.
+For this reason, `rootDir` also enforces that all files which need to be emitted are underneath the `rootDir` path.
+
+For example, let's say you had this tree:
+
+```
+MyProj
+├── tsconfig.json
+├── core
+│   ├── a.ts
+│   ├── b.ts
+├── helpers.ts
+```
+
+It would be an error to specify `rootDir` as `core` _and_ [`include`](#include) as `*` because it creates a file (`helpers.ts`) that would need to be emitted _outside_ the [`outDir`](#outDir) (i.e. `../helpers.js`).

package/docs/tsconfig/rootDirs.md

@@ -0,0 +1,66 @@
+---
+display: 'Root Dirs'
+oneline: 'Allow multiple folders to be treated as one when resolving modules.'
+---
+
+Using `rootDirs`, you can inform the compiler that there are many "virtual" directories acting as a single root.
+This allows the compiler to resolve relative module imports within these "virtual" directories, as if they were merged in to one directory.
+
+For example:
+
+```
+ src
+ └── views
+     └── view1.ts (can import "./template1", "./view2`)
+     └── view2.ts (can import "./template1", "./view1`)
+
+ generated
+ └── templates
+         └── views
+             └── template1.ts (can import "./view1", "./view2")
+```
+
+```json tsconfig
+{
+  "compilerOptions": {
+    "rootDirs": ["src/views", "generated/templates/views"]
+  }
+}
+```
+
+This does not affect how TypeScript emits JavaScript, it only emulates the assumption that they will be able to
+work via those relative paths at runtime.
+
+`rootDirs` can be used to provide a separate "type layer" to files that are not TypeScript or JavaScript by providing a home for generated `.d.ts` files in another folder. This technique is useful for bundled applications where you use `import` of files that aren't necessarily code:
+
+```sh
+ src
+ └── index.ts
+ └── css
+     └── main.css
+     └── navigation.css
+
+ generated
+ └── css
+     └── main.css.d.ts
+     └── navigation.css.d.ts
+```
+
+```json tsconfig
+{
+  "compilerOptions": {
+    "rootDirs": ["src", "generated"]
+  }
+}
+```
+
+This technique lets you generate types ahead of time for the non-code source files. Imports then work naturally based off the source file's location.
+For example `./src/index.ts` can import the file `./src/css/main.css` and TypeScript will be aware of the bundler's behavior for that filetype via the corresponding generated declaration file.
+
+```ts twoslash
+// @filename: main.css.d.ts
+export const appClass = 'mainClassF3EC2';
+// ---cut---
+// @filename: index.ts
+import { appClass } from './main.css';
+```

package/docs/tsconfig/skipDefaultLibCheck.md

@@ -0,0 +1,6 @@
+---
+display: 'Skip Default Lib Check'
+oneline: 'Skip type checking .d.ts files that are included with TypeScript.'
+---
+
+Use [`skipLibCheck`](#skipLibCheck) instead. Skip type checking of default library declaration files.

package/docs/tsconfig/skipLibCheck.md

@@ -0,0 +1,19 @@
+---
+display: 'Skip Lib Check'
+oneline: 'Skip type checking all .d.ts files.'
+---
+
+Skip type checking of declaration files.
+
+This can save time during compilation at the expense of type-system accuracy. For example, two libraries could
+define two copies of the same `type` in an inconsistent way. Rather than doing a full check of all `d.ts` files, TypeScript
+will type check the code you specifically refer to in your app's source code.
+
+A common case where you might think to use `skipLibCheck` is when there are two copies of a library's types in
+your `node_modules`. In these cases, you should consider using a feature like [yarn's resolutions](https://yarnpkg.com/lang/en/docs/selective-version-resolutions/)
+to ensure there is only one copy of that dependency in your tree or investigate how to ensure there is
+only one copy by understanding the dependency resolution to fix the issue without additional tooling.
+
+Another possibility is when you are migrating between TypeScript releases and the changes cause breakages in node_modules and the JS standard libraries which you do not want to deal with during the TypeScript update.
+
+Note, that if these issues come from the TypeScript standard library you can replace the library using [TypeScript 4.5's lib replacement](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modules) technique.