chore(docs): new binary name (#565)

Author: psteinroe

.github/workflows/pull_request.yml

@@ -112,8 +112,9 @@ jobs:
  sleep 1
  done
 
- - name: Install tree-sitter-cli
- run: cargo install tree-sitter-cli
+ - uses: tree-sitter/setup-action@v2
+ with:
+ install-lib: false
 
  - name: Setup sqlx-cli
  run: cargo install sqlx-cli
@@ -170,8 +171,9 @@ jobs:
  - name: Setup Postgres
  uses: ./.github/actions/setup-postgres
 
- - name: Install tree-sitter-cli
- run: cargo install tree-sitter-cli
+ - uses: tree-sitter/setup-action@v2
+ with:
+ install-lib: false
 
  - name: Run tests
  run: cargo test --workspace
@@ -201,8 +203,9 @@ jobs:
  uses: moonrepo/setup-rust@v1
  with:
  cache-base: main
- - name: Install tree-sitter-cli
- run: cargo install tree-sitter-cli
+ - uses: tree-sitter/setup-action@v2
+ with:
+ install-lib: false
  - name: Build main binary
  run: cargo build -p pgt_cli --release
  - name: Setup Bun
@@ -244,8 +247,9 @@ jobs:
  cache-base: main
  env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- - name: Install tree-sitter-cli
- run: cargo install tree-sitter-cli
+ - uses: tree-sitter/setup-action@v2
+ with:
+ install-lib: false
  - name: Ensure RustFMT on nightly toolchain
  run: rustup component add rustfmt --toolchain nightly
  - name: echo toolchain

docs/codegen/src/cli_doc.rs

@@ -11,7 +11,7 @@ pub fn generate_cli_doc(docs_dir: &Path) -> anyhow::Result<()> {
  let new_content = utils::replace_section(
  &content,
  "CLI_REF",
- &pgt_command().render_markdown("postgrestools"),
+ &pgt_command().render_markdown("postgres-language-server"),
  );
 
  fs::write(file_path, &new_content)?;

docs/configuration.md

@@ -54,7 +54,7 @@ You can control the files/folders to process using different strategies, either
 The first way to control which files and folders are processed is to list them in the CLI. In the following command, we only check `file1.sql` and all the files in the `src` folder, because folders are recursively traversed.
 
 ```shell
-postgrestools check file1.js src/
+postgres-language-server check file1.js src/
 ```
 
 ### Control files via configuration

docs/features/linting.md

@@ -54,13 +54,13 @@ The linter can also be used via the CLI for CI integration:
 
 ```bash
 # Lint specific files
-postgrestools check migrations/
+postgres-language-server check migrations/
 
 # With specific rules
-postgrestools check migrations/ --only safety/banDropColumn
+postgres-language-server check migrations/ --only safety/banDropColumn
 
 # Skip certain rules
-postgrestools check migrations/ --skip safety/banDropTable
+postgres-language-server check migrations/ --skip safety/banDropTable
 ```
 
 See the [CLI Reference](../reference/cli.md) for more options, and check the guide on [linting migrations]('../guides/checking_migrations.md').

docs/getting_started.md

@@ -7,7 +7,7 @@ The Postgres Language Server can be installed as a development dependency of you
 We recommend creating a `postgres-language-server.jsonc` configuration file for each project. This eliminates repetitive CLI options and ensures that consistent configuration in your editor. Some options are only available from a configuration file. This step is optional though: if you are happy with the defaults, you don’t need a configuration file. To create the `postgres-language-server.jsonc` file, run the `init` command in the root folder of your project:
 
 ```sh
-postgrestools init
+postgres-language-server init
 ```
 
 You’ll now have a `postgres-language-server.jsonc` file in your directory:
@@ -45,9 +45,9 @@ You’ll now have a `postgres-language-server.jsonc` file in your directory:
 
 [//]: # "END DEFAULT_CONFIGURATION"
 
-Make sure to edit the database connection settings to connect to your local development database. To see all options, run `postgrestools --help`.
+Make sure to edit the database connection settings to connect to your local development database. To see all options, run `postgres-language-server --help`.
 
-You can use your current `postgrestools` version instead of "latest" in the `$schema` URL, e.g. `https://pgtools.dev/0.8.1/schema.json`.
+You can use your current `postgres-language-server` version instead of "latest" in the `$schema` URL, e.g. `https://pg-language-server.com/0.8.1/schema.json`.
 
 ## Usage
 
@@ -59,13 +59,13 @@ The CLI exposes a `check` command that will run all checks on the given files or
 
 ```sh
 # check a specific file
-postgrestools check myfile.sql
+postgres-language-server check myfile.sql
 
 # check a directory
-postgrestools check supabase/migrations
+postgres-language-server check supabase/migrations
 ```
 
-Run `postgrestools --help` for all options. The CLI options take precedence over what is loaded from `postgres-language-server.jsonc`.
+Run `postgres-language-server --help` for all options. The CLI options take precedence over what is loaded from `postgres-language-server.jsonc`.
 
 ### Editor Integrations
 
@@ -78,7 +78,7 @@ The Postgres Language Server is available as an extension in your favorite edito
 
 ### Continuous Integration
 
-Run `postgrestools check` in your CI pipeline to lint your schema changes and enforce code quality across your team. We provide a [GitHub Action](https://github.com/supabase-community/postgrestools-cli-action) to setup the Postgres Language Server in your runner.
+Run `postgres-language-server check` in your CI pipeline to lint your schema changes and enforce code quality across your team. We provide a [GitHub Action](https://github.com/supabase-community/postgrestools-cli-action) to setup the Postgres Language Server in your runner.
 
 See the [Continuous Integration](/guides/continuous_integration) guide for an example.
 

docs/guides/checking_migrations.md

@@ -5,7 +5,7 @@ Postgres Language Tools comes with a `check` command that can be integrated into
 To run it, simply point at your migrations directory.
 
 ```sh
-postgrestools check supabase/migrations
+postgres-language-server check supabase/migrations
 ```
 
 When you are setting it up in an existing project, you might want to ignore all migrations that are already applied. To do so, add `migrationsDir` and `after` to your `postgres-language-server.jsonc` file
@@ -23,7 +23,7 @@ When you are setting it up in an existing project, you might want to ignore all
 Alternatively, pass them directly.
 
 ```
-postgrestools check supabase/migrations --migrations-dir="supabase/migrations" --after=1740868021
+postgres-language-server check supabase/migrations --migrations-dir="supabase/migrations" --after=1740868021
 ```
 
 This will only check migrations after the specified timestamp.

docs/guides/configure_database.md

@@ -45,12 +45,12 @@ Configure database connection details in your `postgres-language-server.jsonc` f
 The language server primarily needs read access to your database schema. Consider creating a dedicated user with limited permissions:
 
 ```sql
-CREATE USER postgrestools_lsp WITH PASSWORD 'secure_password';
-GRANT CONNECT ON DATABASE your_database TO postgrestools_lsp;
-GRANT USAGE ON SCHEMA public TO postgrestools_lsp;
-GRANT SELECT ON ALL TABLES IN SCHEMA public TO postgrestools_lsp;
-GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO postgrestools_lsp;
-GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO postgrestools_lsp;
+CREATE USER postgres_language_server WITH PASSWORD 'secure_password';
+GRANT CONNECT ON DATABASE your_database TO postgres_language_server;
+GRANT USAGE ON SCHEMA public TO postgres_language_server;
+GRANT SELECT ON ALL TABLES IN SCHEMA public TO postgres_language_server;
+GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO postgres_language_server;
+GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO postgres_language_server;
 ```
 
 ### Statement Execution Control
@@ -79,7 +79,7 @@ If you prefer to work without a database connection, you can disable all databas
 Or use the command line flag:
 
 ```bash
-postgrestools check sql/ --disable-db
+postgres-language-server check sql/ --disable-db
 ```
 
 When disabled, you'll still get:

docs/guides/continuous_integration.md

@@ -4,7 +4,7 @@ Running the Postgres Language Server in a CI environment can boost your teams co
 
 ### GitHub Actions
 
-We provide a first-party [GitHub Action](https://github.com/supabase-community/postgrestools-cli-action) to setup the CLI in your runner. Here’s what a simple workflow might look like:
+We provide a first-party [GitHub Action](https://github.com/supabase-community/postgrestools-cli-action) to setup the CLI in your runner. Here's what a simple workflow might look like:
 
 ```yaml
 jobs:
@@ -15,7 +15,7 @@ jobs:
  - uses: supabase-community/pglt-cli-action@main
  with:
  version: latest
- - run: postgrestools check --skip-db sql/
+ - run: postgres-language-server check --skip-db sql/
 ```
 
 You likely want to setup Postgres to enable more advanced checks:
@@ -38,7 +38,7 @@ jobs:
  - uses: supabase-community/pglt-cli-action@main
  with:
  version: latest
- - run: postgrestools check sql/
+ - run: postgres-language-server check sql/
 ```
 
 A common use-case is to check your migration files. Check out [the dedicated guide](./checking_migrations.md) for details.

docs/guides/ide_setup.md

@@ -40,13 +40,13 @@ Using the binary via CLI is very efficient, although you will not be able to pro
 If order to do so, you first need to start a daemon process with the start command:
 
 ```shell
-postgrestools start
+postgres-language-server start
 ```
 
 Then, every command needs to add the `--use-server` options, e.g.:
 
 ```shell
-postgrestools check --use-server --stdin-file-path=dummy.sql
+postgres-language-server check --use-server --stdin-file-path=dummy.sql
 ```
 
 

docs/guides/vcs_integration.md

@@ -50,20 +50,20 @@ First, you have to update your configuration file with the default branch via th
 Add the `--changed` option to your command to process only those files that your VCS acknowledged as “changed”. The language server will determine the changed files from the branch `main` and your current revision:
 
 ```shell
-postgrestools check --changed
+postgres-language-server check --changed
 ```
 
 Alternatively, you can use the option `--since` to specify an arbitrary branch. This option takes precedence over the option `vcs.defaultBranch`. For example, you might want to check your changes against the `next` branch:
 
 ```shell
-postgrestools check --changed --since=next
+postgres-language-server check --changed --since=next
 ```
 
 ## Process only staged files
 
 Before committing your changes, you may want to check the files that have been added to the index, also known as staged files. Add the `--staged` option to process only those files:
 
 ```shell
-postgrestools check --staged
+postgres-language-server check --staged
 ```