ai-hero-cli 0.0.4 → 0.0.6

package/docs/tsconfig/noEmitHelpers.md

@@ -1,38 +0,0 @@
----
-display: 'No Emit Helpers'
-oneline: 'Disable generating custom helper functions like `__extends` in compiled output.'
----
-
-Instead of importing helpers with [`importHelpers`](#importHelpers), you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.
-
-For example, using this `async` function in ES5 requires a `await`-like function and `generator`-like function to run:
-
-```ts twoslash
-const getAPI = async (url: string) => {
-  // Get API
-  return {};
-};
-```
-
-Which creates quite a lot of JavaScript:
-
-```ts twoslash
-// @showEmit
-// @target: ES5
-const getAPI = async (url: string) => {
-  // Get API
-  return {};
-};
-```
-
-Which can be switched out with your own globals via this flag:
-
-```ts twoslash
-// @showEmit
-// @target: ES5
-// @noEmitHelpers
-const getAPI = async (url: string) => {
-  // Get API
-  return {};
-};
-```

package/docs/tsconfig/noEmitOnError.md

@@ -1,8 +0,0 @@
----
-display: 'No Emit On Error'
-oneline: 'Disable emitting files if any type checking errors are reported.'
----
-
-Do not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.
-
-This defaults to `false`, making it easier to work with TypeScript in a watch-like environment where you may want to see results of changes to your code in another environment before making sure all errors are resolved.

package/docs/tsconfig/noErrorTruncation.md

@@ -1,45 +0,0 @@
----
-display: 'No Error Truncation'
-oneline: 'Disable truncating types in error messages.'
----
-
-Do not truncate error messages.
-
-With `false`, the default.
-
-```ts twoslash
-// @errors: 2322 2454
-var x: {
-  propertyWithAnExceedinglyLongName1: string;
-  propertyWithAnExceedinglyLongName2: string;
-  propertyWithAnExceedinglyLongName3: string;
-  propertyWithAnExceedinglyLongName4: string;
-  propertyWithAnExceedinglyLongName5: string;
-  propertyWithAnExceedinglyLongName6: string;
-  propertyWithAnExceedinglyLongName7: string;
-  propertyWithAnExceedinglyLongName8: string;
-};
-
-// String representation of type of 'x' should be truncated in error message
-var s: string = x;
-```
-
-With `true`
-
-```ts twoslash
-// @errors: 2322 2454
-// @noErrorTruncation: true
-var x: {
-  propertyWithAnExceedinglyLongName1: string;
-  propertyWithAnExceedinglyLongName2: string;
-  propertyWithAnExceedinglyLongName3: string;
-  propertyWithAnExceedinglyLongName4: string;
-  propertyWithAnExceedinglyLongName5: string;
-  propertyWithAnExceedinglyLongName6: string;
-  propertyWithAnExceedinglyLongName7: string;
-  propertyWithAnExceedinglyLongName8: string;
-};
-
-// String representation of type of 'x' should be truncated in error message
-var s: string = x;
-```

package/docs/tsconfig/noFallthroughCasesInSwitch.md

@@ -1,22 +0,0 @@
----
-display: 'No Fallthrough Cases In Switch'
-oneline: 'Enable error reporting for fallthrough cases in switch statements.'
----
-
-Report errors for fallthrough cases in switch statements.
-Ensures that any non-empty case inside a switch statement includes either `break`, `return`, or `throw`.
-This means you won't accidentally ship a case fallthrough bug.
-
-```ts twoslash
-// @noFallthroughCasesInSwitch
-// @errors: 7029
-const a: number = 6;
-
-switch (a) {
-  case 0:
-    console.log('even');
-  case 1:
-    console.log('odd');
-    break;
-}
-```

package/docs/tsconfig/noImplicitAny.md

@@ -1,26 +0,0 @@
----
-display: 'No Implicit Any'
-oneline: 'Enable error reporting for expressions and declarations with an implied `any` type.'
----
-
-In some cases where no type annotations are present, TypeScript will fall back to a type of `any` for a variable when it cannot infer the type.
-
-This can cause some errors to be missed, for example:
-
-```ts twoslash
-// @noImplicitAny: false
-function fn(s) {
-  // No error?
-  console.log(s.subtr(3));
-}
-fn(42);
-```
-
-Turning on `noImplicitAny` however TypeScript will issue an error whenever it would have inferred `any`:
-
-```ts twoslash
-// @errors: 7006
-function fn(s) {
-  console.log(s.subtr(3));
-}
-```

package/docs/tsconfig/noImplicitOverride.md

@@ -1,66 +0,0 @@
----
-display: 'No Implicit Override'
-oneline: 'Ensure overriding members in derived classes are marked with an override modifier.'
----
-
-When working with classes which use inheritance, it's possible for a sub-class to get "out of sync" with the functions it overloads when they are renamed in the base class.
-
-For example, imagine you are modeling a music album syncing system:
-
-```ts twoslash
-class Album {
-  download() {
-    // Default behavior
-  }
-}
-
-class SharedAlbum extends Album {
-  download() {
-    // Override to get info from many sources
-  }
-}
-```
-
-Then when you add support for machine-learning generated playlists, you refactor the `Album` class to have a 'setup' function instead:
-
-```ts twoslash
-class Album {
-  setup() {
-    // Default behavior
-  }
-}
-
-class MLAlbum extends Album {
-  setup() {
-    // Override to get info from algorithm
-  }
-}
-
-class SharedAlbum extends Album {
-  download() {
-    // Override to get info from many sources
-  }
-}
-```
-
-In this case, TypeScript has provided no warning that `download` on `SharedAlbum` _expected_ to override a function in the base class.
-
-Using `noImplicitOverride` you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword `override`.
-
-The following example has `noImplicitOverride` enabled, and you can see the error received when `override` is missing:
-
-```ts twoslash
-// @noImplicitOverride
-// @errors: 4114
-class Album {
-  setup() {}
-}
-
-class MLAlbum extends Album {
-  override setup() {}
-}
-
-class SharedAlbum extends Album {
-  setup() {}
-}
-```

package/docs/tsconfig/noImplicitReturns.md

@@ -1,17 +0,0 @@
----
-display: 'No Implicit Returns'
-oneline: 'Enable error reporting for codepaths that do not explicitly return in a function.'
----
-
-When enabled, TypeScript will check all code paths in a function to ensure they return a value.
-
-```ts twoslash
-// @errors: 2366 2322
-function lookupHeadphonesManufacturer(color: 'blue' | 'black'): string {
-  if (color === 'blue') {
-    return 'beats';
-  } else {
-    ('bose');
-  }
-}
-```

package/docs/tsconfig/noImplicitThis.md

@@ -1,28 +0,0 @@
----
-display: 'No Implicit This'
-oneline: 'Enable error reporting when `this` is given the type `any`.'
----
-
-Raise error on 'this' expressions with an implied 'any' type.
-
-For example, the class below returns a function which tries to access `this.width` and `this.height` – but the context
-for `this` inside the function inside `getAreaFunction` is not the instance of the Rectangle.
-
-```ts twoslash
-// @errors: 2683
-class Rectangle {
-  width: number;
-  height: number;
-
-  constructor(width: number, height: number) {
-    this.width = width;
-    this.height = height;
-  }
-
-  getAreaFunction() {
-    return function () {
-      return this.width * this.height;
-    };
-  }
-}
-```

package/docs/tsconfig/noImplicitUseStrict.md

@@ -1,7 +0,0 @@
----
-display: 'No Implicit Use Strict'
-oneline: "Disable adding 'use strict' directives in emitted JavaScript files."
----
-
-You shouldn't need this. By default, when emitting a module file to a non-ES6 target, TypeScript emits a `"use strict";` prologue at the top of the file.
-This setting disables the prologue.

package/docs/tsconfig/noLib.md

@@ -1,9 +0,0 @@
----
-display: 'No Lib'
-oneline: 'Disable including any library files, including the default lib.d.ts.'
----
-
-Disables the automatic inclusion of any library files.
-If this option is set, `lib` is ignored.
-
-TypeScript _cannot_ compile anything without a set of interfaces for key primitives like: `Array`, `Boolean`, `Function`, `IArguments`, `Number`, `Object`, `RegExp`, and `String`. It is expected that if you use `noLib` you will be including your own type definitions for these.

package/docs/tsconfig/noPropertyAccessFromIndexSignature.md

@@ -1,57 +0,0 @@
----
-display: 'No Property Access From Index Signature'
-oneline: 'Enforces using indexed accessors for keys declared using an indexed type.'
----
-
-This setting ensures consistency between accessing a field via the "dot" (`obj.key`) syntax, and "indexed" (`obj["key"]`) and the way which the property is declared in the type.
-
-Without this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:
-
-```ts twoslash
-// @errors: 4111
-declare function getSettings(): GameSettings;
-// ---cut---
-interface GameSettings {
-  // Known up-front properties
-  speed: 'fast' | 'medium' | 'slow';
-  quality: 'high' | 'low';
-
-  // Assume anything unknown to the interface
-  // is a string.
-  [key: string]: string;
-}
-
-const settings = getSettings();
-settings.speed;
-//       ^?
-settings.quality;
-//       ^?
-
-// Unknown key accessors are allowed on
-// this object, and are `string`
-settings.username;
-//       ^?
-```
-
-Turning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.
-
-```ts twoslash
-// @errors: 4111
-// @noPropertyAccessFromIndexSignature
-declare function getSettings(): GameSettings;
-interface GameSettings {
-  speed: 'fast' | 'medium' | 'slow';
-  quality: 'high' | 'low';
-  [key: string]: string;
-}
-// ---cut---
-const settings = getSettings();
-settings.speed;
-settings.quality;
-
-// This would need to be settings["username"];
-settings.username;
-//       ^?
-```
-
-The goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.

package/docs/tsconfig/noResolve.md

@@ -1,9 +0,0 @@
----
-display: 'No Resolve'
-oneline: 'Disallow `import`s, `require`s or `<reference>`s from expanding the number of files TypeScript should add to a project.'
----
-
-By default, TypeScript will examine the initial set of files for `import` and `<reference` directives and add these resolved files to your program.
-
-If `noResolve` is set, this process doesn't happen.
-However, `import` statements are still checked to see if they resolve to a valid module, so you'll need to make sure this is satisfied by some other means.

package/docs/tsconfig/noStrictGenericChecks.md

@@ -1,20 +0,0 @@
----
-display: 'No Strict Generic Checks'
-oneline: 'Disable strict checking of generic signatures in function types.'
----
-
-TypeScript will unify type parameters when comparing two generic functions.
-
-```ts twoslash
-// @errors: 2322
-
-type A = <T, U>(x: T, y: U) => [T, U];
-type B = <S>(x: S, y: S) => [S, S];
-
-function f(a: A, b: B) {
-  b = a; // Ok
-  a = b; // Error
-}
-```
-
-This flag can be used to remove that check.

package/docs/tsconfig/noUncheckedIndexedAccess.md

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

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

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

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

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

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

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

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

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