ai-hero-cli 0.0.3 → 0.0.5

package/docs/tsconfig/sourceMap.md

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

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

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

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

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

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

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

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

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

package/docs/tsconfig/stripInternal.md

@@ -0,0 +1,60 @@
+---
+display: 'Strip Internal'
+oneline: 'Disable emitting declarations that have `@internal` in their JSDoc comments.'
+---
+
+Do not emit declarations for code that has an `@internal` annotation in its JSDoc comment.
+This is an internal compiler option; use at your own risk, because the compiler does not check that the result is valid.
+If you are searching for a tool to handle additional levels of visibility within your `d.ts` files, look at [api-extractor](https://api-extractor.com).
+
+```ts twoslash
+/**
+ * Days available in a week
+ * @internal
+ */
+export const daysInAWeek = 7;
+
+/** Calculate how much someone earns in a week */
+export function weeklySalary(dayRate: number) {
+  return daysInAWeek * dayRate;
+}
+```
+
+With the flag set to `false` (default):
+
+```ts twoslash
+// @showEmittedFile: index.d.ts
+// @showEmit
+// @declaration
+/**
+ * Days available in a week
+ * @internal
+ */
+export const daysInAWeek = 7;
+
+/** Calculate how much someone earns in a week */
+export function weeklySalary(dayRate: number) {
+  return daysInAWeek * dayRate;
+}
+```
+
+With `stripInternal` set to `true` the `d.ts` emitted will be redacted.
+
+```ts twoslash
+// @stripinternal
+// @showEmittedFile: index.d.ts
+// @showEmit
+// @declaration
+/**
+ * Days available in a week
+ * @internal
+ */
+export const daysInAWeek = 7;
+
+/** Calculate how much someone earns in a week */
+export function weeklySalary(dayRate: number) {
+  return daysInAWeek * dayRate;
+}
+```
+
+The JavaScript output is still the same.

package/docs/tsconfig/suppressExcessPropertyErrors.md

@@ -0,0 +1,16 @@
+---
+display: 'Suppress Excess Property Errors'
+oneline: 'Disable reporting of excess property errors during the creation of object literals.'
+---
+
+This disables reporting of excess property errors, such as the one shown in the following example:
+
+```ts twoslash
+// @errors: 2322
+type Point = { x: number; y: number };
+const p: Point = { x: 1, y: 3, m: 10 };
+```
+
+This flag was added to help people migrate to the stricter checking of new object literals in [TypeScript 1.6](/docs/handbook/release-notes/typescript-1-6.html#stricter-object-literal-assignment-checks).
+
+We don't recommend using this flag in a modern codebase, you can suppress one-off cases where you need it using `// @ts-ignore`.

package/docs/tsconfig/suppressImplicitAnyIndexErrors.md

@@ -0,0 +1,25 @@
+---
+display: 'Suppress Implicit Any Index Errors'
+oneline: 'Suppress [`noImplicitAny`](#noImplicitAny) errors when indexing objects that lack index signatures.'
+---
+
+Turning `suppressImplicitAnyIndexErrors` on suppresses reporting the error about implicit anys when indexing into objects, as shown in the following example:
+
+```ts twoslash
+// @noImplicitAny: true
+// @suppressImplicitAnyIndexErrors: false
+// @strict: true
+// @errors: 7053
+const obj = { x: 10 };
+console.log(obj['foo']);
+```
+
+Using `suppressImplicitAnyIndexErrors` is quite a drastic approach. It is recommended to use a `@ts-ignore` comment instead:
+
+```ts twoslash
+// @noImplicitAny: true
+// @strict: true
+const obj = { x: 10 };
+// @ts-ignore
+console.log(obj['foo']);
+```

package/docs/tsconfig/synchronousWatchDirectory.md

@@ -0,0 +1,14 @@
+---
+display: 'Synchronous Watch Directory'
+oneline: 'Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively.'
+---
+
+Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively. Instead of giving a small timeout to allow for potentially multiple edits to occur on a file.
+
+```json tsconfig
+{
+  "watchOptions": {
+    "synchronousWatchDirectory": true
+  }
+}
+```

package/docs/tsconfig/target.md

@@ -0,0 +1,18 @@
+---
+display: 'Target'
+oneline: 'Set the JavaScript language version for emitted JavaScript and include compatible library declarations.'
+---
+
+Modern browsers support all ES6 features, so `ES6` is a good choice.
+You might choose to set a lower target if your code is deployed to older environments, or a higher target if your code is guaranteed to run in newer environments.
+
+The `target` setting changes which JS features are downleveled and which are left intact.
+For example, an arrow function `() => this` will be turned into an equivalent `function` expression if `target` is ES5 or lower.
+
+Changing `target` also changes the default value of [`lib`](#lib).
+You may "mix and match" `target` and `lib` settings as desired, but you could just set `target` for convenience.
+
+For developer platforms like Node there are baselines for the `target`, depending on the type of platform and its version. You can find a set of community organized TSConfigs at [tsconfig/bases](https://github.com/tsconfig/bases#centralized-recommendations-for-tsconfig-bases), which has configurations for common platforms and their versions.
+
+The special `ESNext` value refers to the highest version your version of TypeScript supports.
+This setting should be used with caution, since it doesn't mean the same thing between different TypeScript versions and can make upgrades less predictable.

package/docs/tsconfig/traceResolution.md

@@ -0,0 +1,7 @@
+---
+display: 'Trace Resolution'
+oneline: 'Log paths used during the [`moduleResolution`](#moduleResolution) process.'
+---
+
+When you are trying to debug why a module isn't being included.
+You can set `traceResolution` to `true` to have TypeScript print information about its resolution process for each processed file.

package/docs/tsconfig/tsBuildInfoFile.md

@@ -0,0 +1,17 @@
+---
+display: 'TS Build Info File'
+oneline: 'The file to store `.tsbuildinfo` incremental build information in.'
+---
+
+This setting lets you specify a file for storing incremental compilation information as a part of composite projects which enables faster
+building of larger TypeScript codebases. You can read more about composite projects [in the handbook](/docs/handbook/project-references.html).
+
+The default depends on a combination of other settings:
+
+- If `outFile` is set, the default is `<outFile>.tsbuildinfo`.
+- If `rootDir` and `outDir` are set, then the file is `<outDir>/<relative path to config from rootDir>/<config name>.tsbuildinfo`
+  For example, if `rootDir` is `src`, `outDir` is `dest`, and the config is
+  `./tsconfig.json`, then the default is `./tsconfig.tsbuildinfo`
+  as the relative path from `src/` to `./tsconfig.json` is `../`.
+- If `outDir` is set, then the default is `<outDir>/<config name>.tsbuildInfo`
+- Otherwise, the default is `<config name>.tsbuildInfo`

package/docs/tsconfig/typeAcquisition.md

@@ -0,0 +1,37 @@
+---
+display: 'Type Acquisition'
+oneline: 'Specify options for automatic acquisition of declaration files.'
+---
+
+When you have a JavaScript project in your editor, TypeScript will provide types for your `node_modules` automatically using the DefinitelyTyped set of `@types` definitions.
+This is called automatic type acquisition, and you can customize it using the `typeAcquisition` object in your configuration.
+
+If you would like to disable or customize this feature, create a `jsconfig.json` in the root of your project:
+
+```json
+{
+  "typeAcquisition": {
+    "enable": false
+  }
+}
+```
+
+If you have a specific module which should be included (but isn't in `node_modules`):
+
+```json
+{
+  "typeAcquisition": {
+    "include": ["jest"]
+  }
+}
+```
+
+If a module should not be automatically acquired, for example if the library is available in your `node_modules` but your team has agreed to not use it:
+
+```json
+{
+  "typeAcquisition": {
+    "exclude": ["jquery"]
+  }
+}
+```

package/docs/tsconfig/typeRoots.md

@@ -0,0 +1,21 @@
+---
+display: 'Type Roots'
+oneline: 'Specify multiple folders that act like `./node_modules/@types`.'
+---
+
+By default all _visible_ "`@types`" packages are included in your compilation.
+Packages in `node_modules/@types` of any enclosing folder are considered _visible_.
+For example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.
+
+If `typeRoots` is specified, _only_ packages under `typeRoots` will be included. For example:
+
+```json tsconfig
+{
+  "compilerOptions": {
+    "typeRoots": ["./typings", "./vendor/types"]
+  }
+}
+```
+
+This config file will include _all_ packages under `./typings` and `./vendor/types`, and no packages from `./node_modules/@types`.
+All paths are relative to the `tsconfig.json`.

package/docs/tsconfig/types.md

@@ -0,0 +1,40 @@
+---
+display: 'Types'
+oneline: 'Specify type package names to be included without being referenced in a source file.'
+---
+
+By default all _visible_ "`@types`" packages are included in your compilation.
+Packages in `node_modules/@types` of any enclosing folder are considered _visible_.
+For example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.
+
+If `types` is specified, only packages listed will be included in the global scope. For instance:
+
+```json tsconfig
+{
+  "compilerOptions": {
+    "types": ["node", "jest", "express"]
+  }
+}
+```
+
+This `tsconfig.json` file will _only_ include `./node_modules/@types/node`, `./node_modules/@types/jest` and `./node_modules/@types/express`.
+Other packages under `node_modules/@types/*` will not be included.
+
+### What does this affect?
+
+This option does not affect how `@types/*` are included in your application code, for example if you had the above `compilerOptions` example with code like:
+
+```ts
+import * as moment from 'moment';
+
+moment().format('MMMM Do YYYY, h:mm:ss a');
+```
+
+The `moment` import would be fully typed.
+
+When you have this option set, by not including a module in the `types` array it:
+
+- Will not add globals to your project (e.g `process` in node, or `expect` in Jest)
+- Will not have exports appear as auto-import recommendations
+
+This feature differs from [`typeRoots`](#typeRoots) in that it is about specifying only the exact types you want included, whereas [`typeRoots`](#typeRoots) supports saying you want particular folders.

package/docs/tsconfig/useDefineForClassFields.md

@@ -0,0 +1,10 @@
+---
+display: 'Use Define For Class Fields'
+oneline: 'Emit ECMAScript-standard-compliant class fields.'
+---
+
+This flag is used as part of migrating to the upcoming standard version of class fields. TypeScript introduced class fields many years before it was ratified in TC39. The latest version of the upcoming specification has a different runtime behavior to TypeScript's implementation but the same syntax.
+
+This flag switches to the upcoming ECMA runtime behavior.
+
+You can read more about the transition in [the 3.7 release notes](/docs/handbook/release-notes/typescript-3-7.html#the-usedefineforclassfields-flag-and-the-declare-property-modifier).

package/docs/tsconfig/useUnknownInCatchVariables.md

@@ -0,0 +1,21 @@
+---
+display: 'Use Unknown In Catch Variables'
+oneline: 'Default catch clause variables as `unknown` instead of `any`.'
+---
+
+In TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from `any` to `unknown`. Allowing for code like:
+
+```ts twoslash
+// @useUnknownInCatchVariables
+try {
+  // ...
+} catch (err: unknown) {
+  // We have to verify err is an
+  // error before using it as one.
+  if (err instanceof Error) {
+    console.log(err.message);
+  }
+}
+```
+
+This pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown _is_ a Error subclass ahead of time. With the flag `useUnknownInCatchVariables` enabled, then you do not need the additional syntax (`: unknown`) nor a linter rule to try enforce this behavior.