ai-hero-cli 0.0.4 → 0.0.6

package/docs/tsconfig/preserveConstEnums.md

@@ -1,58 +0,0 @@
----
-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

@@ -1,10 +0,0 @@
----
-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

@@ -1,18 +0,0 @@
----
-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

@@ -1,6 +0,0 @@
----
-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

@@ -1,7 +0,0 @@
----
-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

@@ -1,6 +0,0 @@
----
-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

@@ -1,9 +0,0 @@
----
-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

@@ -1,33 +0,0 @@
----
-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

@@ -1,44 +0,0 @@
----
-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

@@ -1,8 +0,0 @@
----
-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

@@ -1,8 +0,0 @@
----
-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

@@ -1,8 +0,0 @@
----
-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

@@ -1,66 +0,0 @@
----
-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

@@ -1,66 +0,0 @@
----
-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

@@ -1,6 +0,0 @@
----
-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

@@ -1,19 +0,0 @@
----
-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.

package/docs/tsconfig/sourceMap.md

@@ -1,39 +0,0 @@
----
-display: 'Source Map'
-oneline: 'Create source map files for emitted JavaScript files.'
----
-
-Enables the generation of [sourcemap files](https://developer.mozilla.org/docs/Tools/Debugger/How_to/Use_a_source_map).
-These files allow debuggers and other tools to display the original TypeScript source code when actually working with the emitted JavaScript files.
-Source map files are emitted as `.js.map` (or `.jsx.map`) files next to the corresponding `.js` output file.
-
-The `.js` files will in turn contain a sourcemap comment to indicate where the files are to external tools, for example:
-
-```ts
-// helloWorld.ts
-export declare const helloWorld = 'hi';
-```
-
-Compiling with `sourceMap` set to `true` creates the following JavaScript file:
-
-```js
-// helloWorld.js
-'use strict';
-Object.defineProperty(exports, '__esModule', { value: true });
-exports.helloWorld = 'hi';
-//# sourceMappingURL=// helloWorld.js.map
-```
-
-And this also generates this json map:
-
-```json
-// helloWorld.js.map
-{
-  "version": 3,
-  "file": "ex.js",
-  "sourceRoot": "",
-  "sources": ["../ex.ts"],
-  "names": [],
-  "mappings": ";;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA"
-}
-```

package/docs/tsconfig/sourceRoot.md

@@ -1,18 +0,0 @@
----
-display: 'Source Root'
-oneline: 'Specify the root path for debuggers to find the reference source code.'
----
-
-Specify the location where a debugger should locate TypeScript files instead of relative source locations.
-This string is treated verbatim inside the source-map where you can use a path or a URL:
-
-```json tsconfig
-{
-  "compilerOptions": {
-    "sourceMap": true,
-    "sourceRoot": "https://my-website.com/debug/source/"
-  }
-}
-```
-
-Would declare that `index.js` will have a source file at `https://my-website.com/debug/source/index.ts`.

package/docs/tsconfig/stopBuildOnErrors.md

@@ -1,6 +0,0 @@
----
-display: 'stopBuildOnErrors'
-oneline: 'Skip building downstream projects on error in upstream project.'
----
-
-Skip building downstream projects on error in upstream project.

package/docs/tsconfig/strict.md

@@ -1,11 +0,0 @@
----
-display: 'Strict'
-oneline: 'Enable all strict type-checking options.'
----
-
-The `strict` flag enables a wide range of type checking behavior that results in stronger guarantees of program correctness.
-Turning this on is equivalent to enabling all of the _strict mode family_ options, which are outlined below.
-You can then turn off individual strict mode family checks as needed.
-
-Future versions of TypeScript may introduce additional stricter checking under this flag, so upgrades of TypeScript might result in new type errors in your program.
-When appropriate and possible, a corresponding flag will be added to disable that behavior.

package/docs/tsconfig/strictBindCallApply.md

@@ -1,34 +0,0 @@
----
-display: 'Strict Bind Call Apply'
-oneline: 'Check that the arguments for `bind`, `call`, and `apply` methods match the original function.'
----
-
-When set, TypeScript will check that the built-in methods of functions `call`, `bind`, and `apply` are invoked with correct argument for the underlying function:
-
-```ts twoslash
-// @strictBindCallApply: true
-// @errors: 2345
-
-// With strictBindCallApply on
-function fn(x: string) {
-  return parseInt(x);
-}
-
-const n1 = fn.call(undefined, '10');
-
-const n2 = fn.call(undefined, false);
-```
-
-Otherwise, these functions accept any arguments and will return `any`:
-
-```ts twoslash
-// @strictBindCallApply: false
-
-// With strictBindCallApply off
-function fn(x: string) {
-  return parseInt(x);
-}
-
-// Note: No error; return type is 'any'
-const n = fn.call(undefined, false);
-```

package/docs/tsconfig/strictBuiltinIteratorReturn.md

@@ -1,6 +0,0 @@
----
-display: 'strictBuiltinIteratorReturn'
-oneline: 'Built-in iterators are instantiated with a TReturn type of undefined instead of any.'
----
-
-Built-in iterators are instantiated with a `TReturn` type of undefined instead of `any`.

package/docs/tsconfig/strictFunctionTypes.md

@@ -1,55 +0,0 @@
----
-display: 'Strict Function Types'
-oneline: 'When assigning functions, check to ensure parameters and the return values are subtype-compatible.'
----
-
-When enabled, this flag causes functions parameters to be checked more correctly.
-
-Here's a basic example with `strictFunctionTypes` off:
-
-```ts twoslash
-// @strictFunctionTypes: false
-function fn(x: string) {
-  console.log('Hello, ' + x.toLowerCase());
-}
-
-type StringOrNumberFunc = (ns: string | number) => void;
-
-// Unsafe assignment
-let func: StringOrNumberFunc = fn;
-// Unsafe call - will crash
-func(10);
-```
-
-With `strictFunctionTypes` _on_, the error is correctly detected:
-
-```ts twoslash
-// @errors: 2322
-function fn(x: string) {
-  console.log('Hello, ' + x.toLowerCase());
-}
-
-type StringOrNumberFunc = (ns: string | number) => void;
-
-// Unsafe assignment is prevented
-let func: StringOrNumberFunc = fn;
-```
-
-During development of this feature, we discovered a large number of inherently unsafe class hierarchies, including some in the DOM.
-Because of this, the setting only applies to functions written in _function_ syntax, not to those in _method_ syntax:
-
-```ts twoslash
-type Methodish = {
-  func(x: string | number): void;
-};
-
-function fn(x: string) {
-  console.log('Hello, ' + x.toLowerCase());
-}
-
-// Ultimately an unsafe assignment, but not detected
-const m: Methodish = {
-  func: fn,
-};
-m.func(10);
-```

package/docs/tsconfig/strictNullChecks.md

@@ -1,58 +0,0 @@
----
-display: 'Strict Null Checks'
-oneline: 'When type checking, take into account `null` and `undefined`.'
----
-
-When `strictNullChecks` is `false`, `null` and `undefined` are effectively ignored by the language.
-This can lead to unexpected errors at runtime.
-
-When `strictNullChecks` is `true`, `null` and `undefined` have their own distinct types and you'll get a type error if you try to use them where a concrete value is expected.
-
-For example with this TypeScript code, `users.find` has no guarantee that it will actually find a user, but you can
-write code as though it will:
-
-```ts twoslash
-// @strictNullChecks: false
-// @target: ES2015
-declare const loggedInUsername: string;
-
-const users = [
-  { name: 'Oby', age: 12 },
-  { name: 'Heera', age: 32 },
-];
-
-const loggedInUser = users.find((u) => u.name === loggedInUsername);
-console.log(loggedInUser.age);
-```
-
-Setting `strictNullChecks` to `true` will raise an error that you have not made a guarantee that the `loggedInUser` exists before trying to use it.
-
-```ts twoslash
-// @errors: 2339 2532 18048
-// @target: ES2020
-// @strictNullChecks
-declare const loggedInUsername: string;
-
-const users = [
-  { name: 'Oby', age: 12 },
-  { name: 'Heera', age: 32 },
-];
-
-const loggedInUser = users.find((u) => u.name === loggedInUsername);
-console.log(loggedInUser.age);
-```
-
-The second example failed because the array's `find` function looks a bit like this simplification:
-
-```ts
-// When strictNullChecks: true
-type Array = {
-  find(predicate: (value: any, index: number) => boolean): S | undefined;
-};
-
-// When strictNullChecks: false the undefined is removed from the type system,
-// allowing you to write code which assumes it always found a result
-type Array = {
-  find(predicate: (value: any, index: number) => boolean): S;
-};
-```

package/docs/tsconfig/strictPropertyInitialization.md

@@ -1,29 +0,0 @@
----
-display: 'Strict Property Initialization'
-oneline: 'Check for class properties that are declared but not set in the constructor.'
----
-
-When set to true, TypeScript will raise an error when a class property was declared but not set in the constructor.
-
-```ts twoslash
-// @errors: 2564
-class UserAccount {
-  name: string;
-  accountType = 'user';
-
-  email: string;
-  address: string | undefined;
-
-  constructor(name: string) {
-    this.name = name;
-    // Note that this.email is not set
-  }
-}
-```
-
-In the above case:
-
-- `this.name` is set specifically.
-- `this.accountType` is set by default.
-- `this.email` is not set and raises an error.
-- `this.address` is declared as potentially `undefined` which means it does not have to be set.