Node.js API

Use the same upload engine inside a Node.js application. Configure and test a destination through the CLI first, then load that configuration from your app.

Install and initialize

npm install [email protected]

Use an ES module (.mjs, or a project with type: module):

import { PicGo } from 'piclist'

const client = await PicGo.create('/path/to/data.json')
const images = await client.upload(['/absolute/path/image.png'])

if (images instanceof Error) throw images
if (!images.length || !images.every(image => image.imgUrl)) {
  throw new Error('Upload did not return all expected image URLs')
}
const urls = images.map(image => image.imgUrl)

PicGo.create() completes asynchronous initialization. Without a path, it uses the default Core configuration location. Uploading without input reads the clipboard.

Select a destination for one call

const images = await client.upload(['/absolute/path/image.png'], {
  picBed: 'aws-s3-plist',
  configName: 'Docs'
})

The Node API property is picBed; the CLI option is --picbed and the HTTP query parameter is picbed. These options apply to this call without changing saved defaults.

Secondary upload results

upload() returns primary results. To run a configured secondary upload, use uploadReturnCtx():

const result = await client.uploadReturnCtx(['/absolute/path/image.png'])
const primaryImages = result.ctx.output
const secondaryImages = result.backupCtx?.output ?? []

Validate primary and secondary results separately. A secondary failure can be logged without rejecting the primary upload, so primary success alone does not prove both copies exist.

CommonJS

Core 3.0 is an ES module. Use dynamic import from CommonJS:

async function uploadImage() {
  const { PicGo } = await import('piclist')
  const client = await PicGo.create('/path/to/data.json')
  return client.upload(['/absolute/path/image.png'])
}

Configuration and extension

getConfig(key) reads a setting; saveConfig(object) saves settings by dotted field paths. Keep full configurations, upload contexts, and privately signed URLs out of public logs.

See the Core type definitions for plugin and lifecycle interfaces. Desktop scripts have a different execution context; see the script guide.