* Improved Wasp AI CLI experience.
* fix
* Added CLI Usage, polished CLI commands.
* Added choice of temperature.
* Added styling.
* Added more sophisticated, terminal-only styling.
* fix
* Updated Mage to use new Wasp CLI + added some messaging to CLI.
* fix
* Created wasp-ai/README, updated waspc/README.
* Moved wasp-ai/ to mage/.
* Final polishing (docs, readmes, messaging).
* fix
* Added tests for LogMsg.
* Updated versions of test apps to 0.12.
* fix
* fix
* Update mage/README.md
* fix
* fix
* Enable new OpenAI models for MAGE
* Add option to specify Plan GPT model from CLI
* Fix error in parsing planGptModel
* Remove check for GPT-4 availability
* Refactor initialization of GPT params
* Add GPT 3.5 Turbo 0613
* Fix GPT versions to exact values
Generic OpenAI models, such as 'GPT-4' and 'GPT-3_5_turbo',
point to the 'latest' of the respective OpenAI models.
This means that the exact models used can change unexpectedly.
This would not normally be an issue, but the newer models
tend to exhibit a performance drop.
Therefore, to future-proof our application, we fix the
model versions to prevent any unexpected model changes.
* Rename base->coding, plan->planning
* Remove unused _useGpt3IfGpt4NotAvailable field
* Remove confusing helper function
* Fix typo Planing -> Planning
* calculate project root via location of .wasp file
previously, waspls used workspace root, which was incorrect if you opened a
workspace larger than the wasp project.
this does not add support for multi-project workspaces.
* update changelog with waspls scaffolding info
* create directories when scaffolding, if needed
* refresh export cache after scaffolding
* better process for ensuring a blank line between old code and new scaffolded code
Previously, waspls incorrectly thought that importing `@client/file.jsx` could be referencing the file `src/client/file.tsx`. But this JS/TS "merging" is only correct on the server (for reasons that are not explained by the TS documentation on module resolution). This commit fixes that by requiring exact matches for external imports beginning with `@client`.
This incorrect behavior manifested as several different bugs:
- Not reporting missing `.jsx` files when a `.tsx` file with the same name exists.
- Go-to definition going to the `.tsx` file instead of the `.jsx` file when the external import ends in `.jsx`.
- Scaffold actions suggestions scaffolding in both the `.jsx` and `.tsx`files.
This commit fixes all of these buggy behaviors.
When an external import tries to import a symbol from a TypeScript/JavaScript file, waspls now offers quickfix code actions to scaffold a function in that file.
It uses the surrounding context of the external import to determine what code to write for the code action. See [`ScaffoldTsSymbol.hs`](457911d5e9/waspc/waspls/src/Wasp/LSP/Commands/ScaffoldTsSymbol.hs) for a detailed description of how it works. At a high level, there is a `templateForFile` function in `Wasp.LSP.Commands.ScaffoldTsSymbol` that selects the correct template from `data/lsp/templates/ts`. For example, `action.fn.ts` contains a template for scaffolding an `action` function in a TypeScript file and would be used when a code action is requested with the cursor at the location marked by `|`:
```wasp
action createTask {
fn: import { createTask } from "@server/actions.js"|
}
```
The scaffold action runs as a [LSP command](https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#workspace_executeCommand). To prepare for wanting to define more commands in waspls in the future, this PR also introduces the concept of `Commands` (`Wasp.LSP.Commands.Command`) that define some properties about each command waspls wants to handle.