ai-hero-cli 0.0.5 → 0.0.7

package/docs/tsconfig/suppressImplicitAnyIndexErrors.md

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

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

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

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

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

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

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

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

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

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

package/docs/tsconfig/verbatimModuleSyntax.md

@@ -1,148 +0,0 @@
----
-display: 'Verbatim Module Syntax'
-oneline: "Do not transform or elide any imports or exports not marked as type-only, ensuring they are written in the output file's format based on the 'module' setting."
----
-
-By default, TypeScript does something called _import elision_.
-Basically, if you write something like
-
-```ts
-import { Car } from './car';
-
-export function drive(car: Car) {
-  // ...
-}
-```
-
-TypeScript detects that you're only using an import for types and drops the import entirely.
-Your output JavaScript might look something like this:
-
-```js
-export function drive(car) {
-  // ...
-}
-```
-
-Most of the time this is good, because if `Car` isn't a value that's exported from `./car`, we'll get a runtime error.
-
-But it does add a layer of complexity for certain edge cases.
-For example, notice there's no statement like `import "./car";` - the import was dropped entirely.
-That actually makes a difference for modules that have side-effects or not.
-
-TypeScript's emit strategy for JavaScript also has another few layers of complexity - import elision isn't always just driven by how an import is used - it often consults how a value is declared as well.
-So it's not always clear whether code like the following
-
-```ts
-export { Car } from './car';
-```
-
-should be preserved or dropped.
-If `Car` is declared with something like a `class`, then it can be preserved in the resulting JavaScript file.
-But if `Car` is only declared as a `type` alias or `interface`, then the JavaScript file shouldn't export `Car` at all.
-
-While TypeScript might be able to make these emit decisions based on information from across files, not every compiler can.
-
-The `type` modifier on imports and exports helps with these situations a bit.
-We can make it explicit whether an import or export is only being used for type analysis, and can be dropped entirely in JavaScript files by using the `type` modifier.
-
-```ts
-// This statement can be dropped entirely in JS output
-import type * as car from './car';
-
-// The named import/export 'Car' can be dropped in JS output
-import { type Car } from './car';
-export { type Car } from './car';
-```
-
-`type` modifiers are not quite useful on their own - by default, module elision will still drop imports, and nothing forces you to make the distinction between `type` and plain imports and exports.
-So TypeScript has the flag `--importsNotUsedAsValues` to make sure you use the `type` modifier, `--preserveValueImports` to prevent _some_ module elision behavior, and `--isolatedModules` to make sure that your TypeScript code works across different compilers.
-Unfortunately, understanding the fine details of those 3 flags is hard, and there are still some edge cases with unexpected behavior.
-
-TypeScript 5.0 introduces a new option called `--verbatimModuleSyntax` to simplify the situation.
-The rules are much simpler - any imports or exports without a `type` modifier are left around.
-Anything that uses the `type` modifier is dropped entirely.
-
-```ts
-// Erased away entirely.
-import type { A } from 'a';
-
-// Rewritten to 'import { b } from "bcd";'
-import { b, type c, type d } from 'bcd';
-
-// Rewritten to 'import {} from "xyz";'
-import { type xyz } from 'xyz';
-```
-
-With this new option, what you see is what you get.
-
-That does have some implications when it comes to module interop though.
-Under this flag, ECMAScript `import`s and `export`s won't be rewritten to `require` calls when your settings or file extension implied a different module system.
-Instead, you'll get an error.
-If you need to emit code that uses `require` and `module.exports`, you'll have to use TypeScript's module syntax that predates ES2015:
-
-<table>
-<thead>
-    <tr>
-        <th>Input TypeScript</th>
-        <th>Output JavaScript</th>
-    </tr>
-</thead>
-
-<tr>
-<td>
-
-```ts
-import foo = require('foo');
-```
-
-</td>
-<td>
-
-```js
-const foo = require('foo');
-```
-
-</td>
-</tr>
-<tr>
-<td>
-
-```ts
-function foo() {}
-function bar() {}
-function baz() {}
-
-export = {
-  foo,
-  bar,
-  baz,
-};
-```
-
-</td>
-<td>
-
-```js
-function foo() {}
-function bar() {}
-function baz() {}
-
-module.exports = {
-  foo,
-  bar,
-  baz,
-};
-```
-
-</td>
-</tr>
-</table>
-
-While this is a limitation, it does help make some issues more obvious.
-For example, it's very common to forget to set the [`type` field in `package.json`](https://nodejs.org/api/packages.html#type) under `--module node16`.
-As a result, developers would start writing CommonJS modules instead of ES modules without realizing it, giving surprising lookup rules and JavaScript output.
-This new flag ensures that you're intentional about the file type you're using because the syntax is intentionally different.
-
-Because `--verbatimModuleSyntax` provides a more consistent story than `--importsNotUsedAsValues` and `--preserveValueImports`, those two existing flags are being deprecated in its favor.
-
-For more details, read up on [the original pull request](https://github.com/microsoft/TypeScript/pull/52203) and [its proposal issue](https://github.com/microsoft/TypeScript/issues/51479).

package/docs/tsconfig/verbose.md

@@ -1,6 +0,0 @@
----
-display: 'Verbose'
-oneline: 'Enable verbose logging.'
----
-
-Enable verbose logging

package/docs/tsconfig/watchDirectory.md

@@ -1,10 +0,0 @@
----
-display: 'Watch Directory'
-oneline: 'Specify how directories are watched on systems that lack recursive file-watching functionality.'
----
-
-The strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.
-
-- `fixedPollingInterval`: Check every directory for changes several times a second at a fixed interval.
-- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified directories will be checked less often.
-- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for directory changes.

package/docs/tsconfig/watchFile.md

@@ -1,12 +0,0 @@
----
-display: 'Watch File'
-oneline: 'Specify how the TypeScript watch mode works.'
----
-
-The strategy for how individual files are watched.
-
-- `fixedPollingInterval`: Check every file for changes several times a second at a fixed interval.
-- `priorityPollingInterval`: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.
-- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified files will be checked less often.
-- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for file changes.
-- `useFsEventsOnParentDirectory`: Attempt to use the operating system/file system's native events to listen for changes on a file's parent directory

package/prompts/hows-my-tsconfig-score.md

@@ -1,29 +0,0 @@
-You will receive some feedback given about a tsconfig.json file.
-
-Your job is to score how positive the feedback is on a scale of 1 to 10, 10 being the best.
-
-Reply only with the score, no other text.
-
-- 10/10 - Extremely modern and up to date
-- 9/10 - Very modern and up to date
-- 8/10 - Modern and up to date
-- 7/10 - Somewhat modern and up to date
-- 6/10 - Somewhat outdated
-- 5/10 - Outdated
-- 4/10 - Very outdated
-- 3/10 - Extremely outdated
-- 2/10 - Unbelievably outdated
-- 1/10 - The absolute worst
-
-Format it like so, with an emoji next to the score:
-
-10/10 🎉
-9/10 🎉
-8/10 🎉
-7/10 🎉
-6/10 🤔
-5/10 🤔
-4/10 😕
-3/10 😕
-2/10 😕
-1/10 💀

package/prompts/hows-my-tsconfig.md

@@ -1,75 +0,0 @@
-Your name is Matt Pocock. You are a senior software engineer. You are a TypeScript expert.
-
-You are given a tsconfig.json file. You are given a prompt that describes what you should do to improve the tsconfig.json file.
-
-You are to respond with a list of changes you would make to the tsconfig.json file.
-
-You should recommend to the user that they read the TSConfig Cheat Sheet: https://www.totaltypescript.com/tsconfig-cheat-sheet
-
-## Rules
-
-If the tsconfig has `forceConsistentCasingInFileNames`, recommend removing it. It's set to `true` by default since TypeScript 5.0.
-
-If the tsconfig has `erasableSyntaxOnly`, pat the user on the back and say they're fighting the good fight against enums, namespaces and class parameter properties.
-
-If the tsconfig does not have `noImplicitOverride`, recommend adding it.
-
-Do not recommend `exactOptionalPropertyTypes` - but don't say to remove it either. It's fine if you like it, but I personally don't.
-
-If the user does not have `lib` set, recommend adding it. They can set it to the same value as `target`. `lib` can be used to exclude the `dom` types if needed. Node applications mostly won't need `dom` types - but sites that use the DOM will.
-
-If they have `dom` in `lib`, then ensure they also have `dom.iterable` there too.
-
-`noUncheckedIndexedAccess: true` is a useful option to have because it catches errors where you might be accessing an index that doesn't exist. But if the user doesn't want it, don't push them to add it.
-
-`moduleDetection: "force"` forces every non-declaration file to be treated as a module. This is very useful - since most projects will be using modules instead of global scripts.
-
-If the tsconfig doesn't have `strict: true`, strongly recommend adding it. This is the most important setting for catching bugs early.
-
-If the user has `strict: true` but also has individual strict flags set explicitly, recommend removing the redundant ones since `strict: true` includes them all.
-
-For projects that need to be extra safe, recommend `noUnusedLocals: true` and `noUnusedParameters: true` to catch dead code.
-
-### Module Options
-
-There are only two valid options for `module`: `Preserve` and `NodeNext`.
-
-If the user has `noEmit` set to `false`, or not specified, then the best config for them is `module: "NodeNext"`. The reason for this is so that their imports match the behaviour they have set up in their `package.json`. If they have `package.json#type` set to `module`, then they will be using `import/export` imports (ESM). If they have `package.json#type` set to `commonjs` (or not set), then they should be using `require` imports.
-
-If the user has `moduleResolution` set to `node`, recommend they use `NodeNext` instead and remove the `moduleResolution` option.
-
-If the user is targeting modern environments (ES2020+), recommend setting `target` to `"ES2022"` or higher for better performance.
-
-For projects using modern JavaScript features, recommend `allowUnreachableCode: false` to catch dead code.
-
-If the user is building a library, recommend `declaration: true` to generate `.d.ts` files.
-
-For better IDE experience, recommend `sourceMap: true` to enable debugging of TypeScript files.
-
-If the user is using a bundler like Vite or Webpack, they might want `noEmit: true` since the bundler handles compilation.
-
-## Implicit Inheritances
-
-If some tsconfig.json options are set to `true`, others are automatically set to `true` as well. This means that the user doesn't need to set them.
-
-`verbatimModuleSyntax: true` -> `isolatedModules: true`
-
-`strict: true` -> `noImplicitAny: true`, `noImplicitThis: true`, `strictNullChecks: true`, `strictFunctionTypes: true`, `strictBindCallApply: true`, `strictPropertyInitialization: true`, `noImplicitReturns: true`, `useUnknownInCatchVariables: true`, `strictBuiltinIteratorReturn: true`
-
-`esModuleInterop: true` -> `allowSyntheticDefaultImports: true`
-
-`module: "node16"` -> `moduleResolution: "node16"`
-
-`module: "node18"` -> `moduleResolution: "node18"`
-
-`module: "nodenext"` -> `moduleResolution: "nodenext"`
-
-`target: "ES2022"` -> `lib: ["ES2022", "DOM", "DOM.Iterable"]` (if lib is not explicitly set)
-
-## Docs
-
-Below, I've added the docs for each of the options that are set in the tsconfig.json file.
-
-Use the docs to help you understand the options and how they work. Also use them to inform your recommendations.
-
-{{docs}}