@gunshi/docs 0.27.0-beta.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,294 @@
1
+ # Plugin System Introduction
2
+
3
+ Gunshi's plugin system is a powerful feature that enables you to extend your CLI applications with reusable functionality, type-safe interfaces, and composable behaviors.
4
+
5
+ This comprehensive system allows you to build modular, maintainable, and extensible command-line tools.
6
+
7
+ ## Why Plugins?
8
+
9
+ The plugin system addresses several key challenges in CLI development:
10
+
11
+ ### 1. Separation of Concerns
12
+
13
+ Plugins allow you to separate core command logic from cross-cutting concerns like logging, authentication, database connections, and rendering.
14
+
15
+ This separation makes your code more organized and easier to maintain.
16
+
17
+ ### 2. Reusability
18
+
19
+ Once you create a plugin, you can reuse it across multiple commands and even different CLI applications.
20
+
21
+ This reduces code duplication and development time.
22
+
23
+ ### 3. Type Safety
24
+
25
+ Gunshi's plugin system is built with TypeScript-first design, providing full type safety for plugin extensions and their interactions.
26
+
27
+ You get compile-time validation and IntelliSense support throughout your development.
28
+
29
+ ### 4. Ecosystem
30
+
31
+ The plugin architecture enables a rich ecosystem where developers can share and compose plugins.
32
+
33
+ Official plugins provide common functionality, while you can create custom plugins for your specific needs.
34
+
35
+ ## Plugin System Concepts
36
+
37
+ ### Plugin Philosophy
38
+
39
+ Gunshi plugins follow these core principles:
40
+
41
+ - **Composability**: Plugins can be combined and work together seamlessly
42
+ - **Type Safety**: Full TypeScript support with compile-time validation
43
+ - **Lifecycle Awareness**: Plugins integrate at specific points in the CLI lifecycle
44
+ - **Dependency Management**: Automatic resolution of plugin dependencies
45
+ - **Extension Pattern**: Plugins extend command contexts with new capabilities
46
+
47
+ ### Plugin Architecture
48
+
49
+ ```mermaid
50
+ graph TD
51
+ A[CLI Application] --> B[Plugin System]
52
+ B --> C[Plugin Registration]
53
+ C --> D[Dependency Resolution]
54
+ D --> E[Setup Phase]
55
+ E --> F[Extension Creation]
56
+ F --> G[Command Execution]
57
+
58
+ H[Plugin 1] --> C
59
+ I[Plugin 2] --> C
60
+ J[Plugin 3] --> C
61
+
62
+ H -.->|depends on| I
63
+ I -.->|optional| J
64
+ ```
65
+
66
+ This diagram illustrates the plugin system's execution flow.
67
+
68
+ When a CLI application starts, plugins are registered and their dependencies are resolved. During the setup phase, each plugin's initialization code runs.
69
+
70
+ Extensions are then created and made available to commands during execution.
71
+
72
+ Plugins can depend on each other (solid lines) or have optional dependencies (dotted lines).
73
+
74
+ ## Package vs Entry Point
75
+
76
+ Gunshi provides two ways to work with plugins:
77
+
78
+ ### Package: `@gunshi/plugin`
79
+
80
+ The `@gunshi/plugin` package is a complete plugin development kit:
81
+
82
+ ::: code-group
83
+
84
+ ```sh [npm]
85
+ npm install --save @gunshi/plugin
86
+ ```
87
+
88
+ ```sh [pnpm]
89
+ pnpm add @gunshi/plugin
90
+ ```
91
+
92
+ ```sh [yarn]
93
+ yarn add @gunshi/plugin
94
+ ```
95
+
96
+ ```sh [deno]
97
+ deno add jsr:@gunshi/plugin
98
+ ```
99
+
100
+ ```sh [bun]
101
+ bun add @gunshi/plugin
102
+ ```
103
+
104
+ :::
105
+
106
+ Use this package when:
107
+
108
+ - Building standalone plugin packages
109
+ - Creating plugins with complex type definitions
110
+ - Developing plugins for distribution
111
+ - Need access to all plugin utilities and types
112
+
113
+ ```ts
114
+ // Using the package for plugin development
115
+ import { plugin } from '@gunshi/plugin'
116
+ import type { PluginContext } from '@gunshi/plugin'
117
+
118
+ export default function myPlugin() {
119
+ return plugin({
120
+ id: 'my-plugin',
121
+ setup: (ctx: PluginContext) => {
122
+ // Plugin implementation
123
+ }
124
+ })
125
+ }
126
+ ```
127
+
128
+ ### Entry Point: `gunshi/plugin`
129
+
130
+ The `gunshi/plugin` entry point provides essential plugin functionality:
131
+
132
+ ```js
133
+ // Using the entry point for simple plugins
134
+ import { plugin } from 'gunshi/plugin'
135
+
136
+ export default plugin({
137
+ id: 'simple',
138
+ setup: ctx => {
139
+ // Simple plugin logic
140
+ }
141
+ })
142
+ ```
143
+
144
+ Use the entry point when:
145
+
146
+ - Creating simple, application-specific plugins
147
+ - Building inline plugins within your CLI
148
+ - Want to minimize external dependencies
149
+
150
+ ## Plugin Ecosystem Overview
151
+
152
+ ### Official Plugins
153
+
154
+ Gunshi provides several official plugins that cover common CLI needs:
155
+
156
+ #### Core Plugins (Built-in)
157
+
158
+ - **`@gunshi/plugin-global`**: Adds `--help`, `--version` options, version, header, usage and validation errors rendering helpers
159
+ - **`@gunshi/plugin-renderer`**: Provides usage and help core renderer
160
+
161
+ #### Optional Plugins
162
+
163
+ - **`@gunshi/plugin-i18n`**: Internationalization support
164
+ - **`@gunshi/plugin-completion`**: Shell completion functionality
165
+
166
+ ### Community Plugins
167
+
168
+ The plugin architecture enables the community to create and share plugins.
169
+
170
+ ### Custom Plugins
171
+
172
+ You can create custom plugins tailored to your specific needs:
173
+
174
+ ```ts
175
+ // Domain-specific plugin for your application
176
+ export default plugin({
177
+ id: 'api',
178
+ extension: () => ({
179
+ client: new ApiClient(),
180
+ authenticate: async (token: string) => {
181
+ // Custom authentication logic
182
+ }
183
+ })
184
+ })
185
+ ```
186
+
187
+ ## Plugin Capabilities
188
+
189
+ ### 1. Add Global Options
190
+
191
+ Plugins can register global options that will be available to all commands:
192
+
193
+ ```js
194
+ setup: ctx => {
195
+ ctx.addGlobalOption('debug', {
196
+ type: 'boolean',
197
+ description: 'Enable debug mode'
198
+ })
199
+ }
200
+ ```
201
+
202
+ ### 2. Register Sub-Commands
203
+
204
+ Plugins can dynamically register new sub-commands during the setup phase:
205
+
206
+ ```js
207
+ setup: ctx => {
208
+ ctx.addCommand('plugin-command', {
209
+ name: 'plugin-command',
210
+ run: ctx => console.log('Plugin command executed')
211
+ })
212
+ }
213
+ ```
214
+
215
+ ### 3. Decorate Renderers
216
+
217
+ Plugins can enhance or modify the built-in renderers to customize output:
218
+
219
+ ```js
220
+ setup: ctx => {
221
+ ctx.decorateUsageRenderer(async (baseRenderer, ctx) => {
222
+ const base = await baseRenderer(ctx)
223
+ return `${base}\n\nEnhanced by plugin`
224
+ })
225
+ }
226
+ ```
227
+
228
+ ### 4. Extend Command Context
229
+
230
+ Plugins can extend the `CommandContext` with additional functionality that commands can access:
231
+
232
+ ```js
233
+ extension: () => ({
234
+ database: new Database(),
235
+ cache: new Cache(),
236
+ logger: new Logger()
237
+ })
238
+ ```
239
+
240
+ ### 5. Intercept Command Execution
241
+
242
+ Plugins can intercept and modify command execution using decorators:
243
+
244
+ ```js
245
+ setup: ctx => {
246
+ ctx.decorateCommand(baseRunner => async ctx => {
247
+ console.log('Before command')
248
+ const result = await baseRunner(ctx)
249
+ console.log('After command')
250
+ return result
251
+ })
252
+ }
253
+ ```
254
+
255
+ ## Getting Started
256
+
257
+ To start using plugins in your Gunshi CLI:
258
+
259
+ 1. **Use Built-in Plugins**: The default `cli` function includes essential plugins
260
+ 2. **Add Official Plugins**: Install and configure official plugins as needed
261
+ 3. **Create Custom Plugins**: Build plugins specific to your application
262
+ 4. **Share Plugins**: Publish reusable plugins for the community
263
+
264
+ The following is an example of code for installing the official `@gunshi/plugin-i18n` and application-specific plugins:
265
+
266
+ ```js
267
+ import { cli } from 'gunshi'
268
+ import i18n from '@gunshi/plugin-i18n'
269
+ import custom from './plugins/custom.js'
270
+
271
+ const entry = ctx => {}
272
+
273
+ await cli(args, entry, {
274
+ plugins: [i18n({ locale: 'en-US' }), custom()]
275
+ })
276
+ ```
277
+
278
+ ## Next Steps
279
+
280
+ Now that you understand what plugins are and how they enhance Gunshi CLIs, it's time to start building your own plugins.
281
+
282
+ The plugin development learning journey follows a progression:
283
+
284
+ - **[Getting Started](./getting-started.md)** - Create your first plugin with simple examples and learn the basic plugin structure
285
+ - **[Plugin Lifecycle](./lifecycle.md)** - Understand when and how plugins execute during CLI runtime
286
+ - **[Plugin Dependencies](./dependencies.md)** - Build plugin ecosystems with proper dependency management
287
+ - **[Plugin Decorators](./decorators.md)** - Wrap and enhance existing functionality with decorators
288
+ - **[Plugin Extensions](./extensions.md)** - Share features across commands through context extensions
289
+ - **[Plugin Type System](./type-system.md)** - Ensure type safety throughout your plugin implementation
290
+ - **[Plugin Testing](./testing.md)** - Write comprehensive tests for your plugins
291
+ - **[Plugin Development Guidelines](./guidelines.md)** - Follow production-ready patterns and conventions
292
+ - **[Plugin List](./list.md)** - Explore official and community plugins
293
+
294
+ Start with [Getting Started](./getting-started.md) to create your first plugin and experience the plugin development workflow firsthand.