v3.1.0

Features

Choose an Uploader Configuration for Each Upload

You can now choose an existing uploader configuration for an individual upload through the CLI, PicGo Server, or Core API, without changing your saved default uploader or active configuration (#203).

This works with multiple uploader types and multiple saved configurations of the same type. For example, send one image to your work GitHub repository and the next to your personal repository without switching the global configuration.

How to use — CLI:

# Upload a file using an existing configuration named Work.
picgo upload image.png --configName=Work

# Specify the uploader type when the name is shared by multiple types.
picgo upload image.png --uploader=github --configName=Work

# Use a stable configuration ID instead of a name.
picgo upload image.png --uploader=github --configId=your-config-id

# Upload from the clipboard using the same configuration.
picgo upload --uploader=github --configName=Work

Both --configName=Work and --configName Work are supported. The picgo u alias and --format json continue to work.

How to use — PicGo Server:

curl -X POST \
  'http://127.0.0.1:36677/upload?uploader=github&configName=Work' \
  -H 'Content-Type: application/json' \
  -d '{"list":["/absolute/path/image.png"]}'

To upload by configuration ID, use POST /upload?uploader=github&configId=your-config-id instead.

The same query parameters work with JSON file lists, multipart uploads using the files field, and clipboard uploads with an empty body. Existing server authentication still applies. Chinese configuration names are supported; use URLSearchParams to encode names containing Unicode, spaces, or reserved characters.

How to use — Core API:

import { PicGo } from 'picgo'

const picgo = new PicGo()

await picgo.upload(['/absolute/path/image.png'], {
  uploader: 'github',
  configName: 'Work'
})

// Use a stable configuration ID instead of a name.
await picgo.upload(['/absolute/path/image.png'], {
  uploader: 'github',
  configId: 'your-config-id'
})

Configuration lookup:

• configName is matched case-insensitively, ignoring surrounding whitespace. Without uploader, the name must identify exactly one configuration across registered uploader types.
• configId is also supported as a stable identifier. When both ID and name are supplied, a unique ID match takes precedence; otherwise lookup falls back to the name.
• Passing only uploader uses that type's currently active configuration.
• Invalid, missing, or ambiguous configurations return a descriptive HTTP 400 response or reject the SDK call with UploadOptionError, rather than silently uploading to another destination.

When these options are omitted, existing configuration behavior is unchanged. PicGo Cloud continues to use the current logged-in account; these options do not switch Cloud accounts.

For plugin authors and integrations

Uploaders and lifecycle plugins should read configuration from the context passed to their handler. For uploads with explicit options, this context provides an independent configuration snapshot: temporary setConfig / unsetConfig changes stay within the upload, while explicit saveConfig / removeConfig calls retain their persistence behavior.

Custom server upload adapters must forward the optional upload options to picgo.upload. Plugins that cache configuration from the global instance may need to use the handler context instead.

Bug fixes

• Fix lifecycle state being shared between concurrent uploads, which could cause successful items from a partially failed upload to miss their after-upload processing.
• Isolate multipart temporary files per request and per file, preventing same-name files from overwriting each other or being removed by another request's cleanup.
• Tie generated clipboard-file cleanup to its own upload. Existing local files are retained, and clipboard filenames keep the established YYYYMMDDHHmmssSSS.png format for compatibility with integrations.

Full changelog: v3.0.2...v3.1.0