@storepress/get-plugin-data

Parse WordPress plugin file headers from Node — a port of WP core's get_plugin_data() with CLI auto-detection.

CLI

Run from inside a plugin directory; it auto-detects the entry PHP file.

# Single field
npx -y @storepress/get-plugin-data Version
# 1.0.0

npx -y @storepress/get-plugin-data TextDomain
# my-plugin

# All fields as JSON (default)
npx -y @storepress/get-plugin-data

# Shell env (CI-friendly)
eval "$(npx -y @storepress/get-plugin-data --format=env)"
echo "$WP_VERSION"

# Tab-separated lines
npx -y @storepress/get-plugin-data --format=line

# Bypass auto-detect
npx -y @storepress/get-plugin-data Version --file=./my-plugin.php

# Run from elsewhere
npx -y @storepress/get-plugin-data Version --cwd=./plugins/my-plugin

Options

| Flag | Description | | ---------------- | ------------------------------------------------------------------- | | [field] | Field name to print (case-insensitive). Omit to print all. | | --cwd <path> | Directory to scan for the entry file. Defaults to process.cwd(). | | --file <path> | Parse a specific file, skipping auto-detection. | | --format <fmt> | json (default), env, or line. | | -h, --help | Show help. |

Programmatic API

import {
	getPluginData,
	getPluginDataSync,
	findPluginEntry,
	parsePluginHeader,
} from '@storepress/get-plugin-data';

// Async — read and parse a file
const data = await getPluginData( './my-plugin.php' );
// { Name: 'My Plugin', Version: '1.0.0', TextDomain: 'my-plugin', ... }

// Sync variant
const data2 = getPluginDataSync( './my-plugin.php' );

// Auto-detect entry file in a directory
const entry = await findPluginEntry( './my-plugin' );
// './my-plugin/my-plugin.php' or null

// Parse a string directly
const data3 = parsePluginHeader( phpSource );

// Custom header map (e.g. for themes or extra fields)
const data4 = parsePluginHeader( phpSource, {
	headers: {
		Name:        'Theme Name',
		ThemeURI:    'Theme URI',
		Version:     'Version',
		Template:    'Template',
	},
} );

Returned shape

Keys mirror WordPress core's get_plugin_data():

Name, PluginURI, Version, Description, Author, AuthorURI,
TextDomain, DomainPath, Network, RequiresWP, RequiresPHP,
UpdateURI, RequiresPlugins, License, LicenseURI

Missing headers come back as empty strings, matching WP's behavior.

Detection logic

The CLI scans top-level *.php files only (same scope as WP's plugin loader), prefers a file whose basename matches the directory name (the my-plugin/my-plugin.php convention), and returns the first one whose first 8KB contains a Plugin Name: header. uninstall.php, index.php shims, and helper files are filtered out naturally because they lack that header. Bundled libraries inside subdirectories are not scanned, so vendored plugin headers (e.g. ACF inside vendor/) won't be picked up. Use --file for non-standard layouts.

Why 8KB?

WordPress reads only the first 8192 bytes of a plugin file when extracting headers. This package matches that, so a plugin that "passes" here also loads in WP. A header buried below that line will fail in both places — the same way.

Github Tag

• Push Tag git tag $(node -p "require('./package.json').version") && git push origin "$_"
• Delete Tag git tag -d $(node -p "require('./package.json').version") && git push origin --delete "$_"

License

GPL-2.0-or-later