# How PicList-Core CLI Commands config-list and config-use Manage Uploader Configurations

> Discover how PicList-Core CLI commands config-list and config-use manage uploader configurations through the ConfigManager class for seamless JSON storage and synchronization.

- Repository: [Kuingsmile/piclist-core](https://github.com/kuingsmile/piclist-core)
- Tags: how-to-guide
- Published: 2026-03-05

---

**PicList-Core's `config-list` and `config-use` commands provide multi-configuration management for uploaders by interfacing with a centralized `ConfigManager` class that handles JSON configuration storage, migration, and synchronization.**

PicList-Core extends the PicGo ecosystem with robust support for multiple named configurations per uploader. The CLI exposes dedicated commands for listing and switching between these configurations efficiently. This article examines the internal mechanics of the `config-list` and `config-use` commands based on the actual implementation in the `kuingsmile/piclist-core` repository.

## How Config Commands Work in PicList-Core

The CLI operates through a **commander-style plugin system** where commands are registered in [`src/plugins/commander/configManager.ts`](https://github.com/kuingsmile/piclist-core/blob/main/src/plugins/commander/configManager.ts). When the CLI initializes, it creates an `IPicGo` context (`ctx`) that injects core dependencies into each command handler. This context provides access to `ctx.configManager` (the configuration wrapper), `ctx.log` (logging utilities), and `ctx.saveConfig` / `ctx.getConfig` (persistence methods).

The actual configuration logic resides in the **`ConfigManager`** class located at [`src/utils/configManager.ts`](https://github.com/kuingsmile/piclist-core/blob/main/src/utils/configManager.ts). This utility manages the JSON configuration file, handles migration from legacy single-config formats to multi-config arrays, and maintains backward compatibility with legacy `picBed` keys.

## The config-list Command

### Command Syntax and Arguments

The `config-list` command accepts a single required argument specifying the uploader identifier (e.g., `smms`, `imgur`, `github`).

```bash
picgo config-list <uploader>

```

Example execution:

```bash
picgo config-list smms

```

### Implementation Details

In [`src/plugins/commander/configManager.ts`](https://github.com/kuingsmile/piclist-core/blob/main/src/plugins/commander/configManager.ts), the command handler retrieves data through two primary methods. First, it invokes **`ctx.configManager.getAllUploaderConfigs(uploader)`**, which automatically ensures the configuration has been migrated to the multi-config format via `migrateToMultiConfig`, then extracts the array from `ctx.getConfig('uploader.<uploader>')`. Second, it identifies the active default configuration using **`ctx.configManager.getCurrentUploaderConfig(uploader)`**.

The command output displays each configuration name, explicitly marks which entry is currently set as the default, and reveals the internal UUID (`_id`) assigned to each configuration object for precise identification.

## The config-use Command

### Command Syntax and Arguments

The `config-use` command requires two arguments: the uploader name and the specific configuration name to activate as the new default.

```bash
picgo config-use <uploader> <configName>

```

Practical example:

```bash
picgo config-use smms MyPersonalConfig

```

### Setting the Default Configuration

The command handler first validates the target configuration exists by calling **`ctx.configManager.getConfigByName(uploader, configName)`** in [`src/utils/configManager.ts`](https://github.com/kuingsmile/piclist-core/blob/main/src/utils/configManager.ts). Upon validation, it executes **`ctx.configManager.setDefaultConfig(uploader, config._id)`**.

The `setDefaultConfig` method performs three critical operations atomically: it updates the `defaultId` field within the uploader's configuration array to point to the selected config's `_id`, persists the entire configuration object to disk via `ctx.saveConfig()`, and synchronizes the selected configuration values back to the legacy `picBed.<uploader>` key through `syncConfigToPicBed`. This dual-write strategy ensures backward compatibility with older plugins while enabling the new multi-config architecture. The command reports success or failure through `ctx.log` with appropriate status indicators.

## Configuration Architecture

The **`ConfigManager`** class in [`src/utils/configManager.ts`](https://github.com/kuingsmile/piclist-core/blob/main/src/utils/configManager.ts) serves as the definitive abstraction layer for all configuration operations in PicList-Core. It handles automatic migration from legacy single-configuration setups to the modern multi-config format that supports unlimited named configurations per uploader. Each configuration entry receives a unique UUID in its `_id` field, while the `defaultId` property tracks which configuration is currently active for that uploader type.

## Summary

- The `config-list` and `config-use` commands are registered in [`src/plugins/commander/configManager.ts`](https://github.com/kuingsmile/piclist-core/blob/main/src/plugins/commander/configManager.ts) as part of the commander plugin system that receives the PicGo context (`ctx`).
- Both commands delegate file operations to **`ctx.configManager`**, which provides methods like `getAllUploaderConfigs`, `getConfigByName`, and `setDefaultConfig` defined in [`src/utils/configManager.ts`](https://github.com/kuingsmile/piclist-core/blob/main/src/utils/configManager.ts).
- The system automatically migrates legacy configurations to a multi-config format that stores arrays under `uploader.<uploaderName>` keys while maintaining legacy `picBed` compatibility.
- When switching configurations, `config-use` updates the `defaultId` pointer, saves the configuration to disk, and synchronizes values to legacy keys for backward compatibility with existing workflows.

## Frequently Asked Questions

### Where are the config-list and config-use commands defined?

These commands are defined in [`src/plugins/commander/configManager.ts`](https://github.com/kuingsmile/piclist-core/blob/main/src/plugins/commander/configManager.ts) as actions registered with the commander instance via `cmd.program.command()`. Each command receives the PicGo context (`ctx`) as an argument, providing access to the configuration manager and logging utilities implemented in [`src/utils/configManager.ts`](https://github.com/kuingsmile/piclist-core/blob/main/src/utils/configManager.ts).

### How does PicList-Core store multiple configurations for one uploader?

The system stores configurations in an array format under the `uploader.<uploaderName>` key in the JSON configuration file. The `ConfigManager` class automatically migrates legacy single-config setups to this format, maintaining an array of configuration objects each with a unique `_id` field and a `defaultId` property that indicates which configuration is currently active.

### What happens when I run config-use to switch configurations?

When you execute `config-use`, the system validates the configuration name exists using `getConfigByName`, then calls `setDefaultConfig` which updates the `defaultId` field for that uploader, persists the change to disk via `ctx.saveConfig()`, and synchronizes the selected configuration values back to the legacy `picBed.<uploader>` location to maintain compatibility with older plugins and external tools.

### Can I use these commands with any uploader plugin?

Yes, these commands work with any uploader that PicList-Core supports, including built-in uploaders like `smms`, `imgur`, or `github`, as well as third-party plugins. The commands use the uploader name as the primary identifier to fetch and modify configuration arrays in the centralized config store, regardless of the specific uploader implementation.