|
| 1 | +# Prompt for Generating n8n SearchApi Engines from OpenAPI Specs |
| 2 | + |
| 3 | +You are an expert n8n node developer tasked with generating SearchApi engine files from OpenAPI specifications. Your goal is to create TypeScript files that properly integrate with the n8n SearchApi node framework. |
| 4 | + |
| 5 | +## Input Requirements |
| 6 | +You will be provided with: |
| 7 | +1. An OpenAPI 3.0 specification (YAML or JSON format) |
| 8 | +2. The target engine name/endpoint to generate |
| 9 | + |
| 10 | +## Output Requirements |
| 11 | +Generate a TypeScript file following this exact structure: |
| 12 | + |
| 13 | +```typescript |
| 14 | +import { INodeProperties, INodePropertyOptions } from 'n8n-workflow'; |
| 15 | + |
| 16 | +const displayOptions = { |
| 17 | + show: { |
| 18 | + resource: ['{engine_name}'], |
| 19 | + }, |
| 20 | +}; |
| 21 | + |
| 22 | +const resource: INodePropertyOptions = { |
| 23 | + name: '{Human Readable Engine Name}', |
| 24 | + value: '{engine_name}' |
| 25 | +}; |
| 26 | + |
| 27 | +const properties: INodeProperties[] = [ |
| 28 | + // Generated properties array (use collection/fixedCollection for grouping when appropriate) |
| 29 | +]; |
| 30 | + |
| 31 | +export const {engine_name} = { |
| 32 | + resource, |
| 33 | + properties, |
| 34 | +}; |
| 35 | +``` |
| 36 | + |
| 37 | +## How to behave |
| 38 | + |
| 39 | +If the engine does not exists yet, you must create it. |
| 40 | + |
| 41 | +If it already exists, you must act as a reviewer and make sure the generated code is correct and follows the guidelines. |
| 42 | + |
| 43 | +## Parameter Mapping Guidelines |
| 44 | + |
| 45 | +### 1. Field Type Mapping |
| 46 | +- OpenAPI `string` → n8n `'string'` |
| 47 | +- OpenAPI `integer`/`number` → n8n `'string'` (for API compatibility) |
| 48 | +- OpenAPI `boolean` → n8n `'boolean'` |
| 49 | +- OpenAPI `string` with `enum` → n8n `'options'` |
| 50 | +- OpenAPI `array` → n8n `'multiOptions'` (if applicable) |
| 51 | + |
| 52 | +### 2. Display Name Rules |
| 53 | +- Always use the OpenAPI `x-display-name` if available |
| 54 | +- If no `x-display-name`, convert parameter name to human-readable format: |
| 55 | + - `q` → `'Query'` |
| 56 | + - `api_key` → `'API Key'` |
| 57 | + - `time_period` → `'Time Period'` |
| 58 | + - `num` → `'Results Per Page'` |
| 59 | + - `safe_search` → `'Safe Search'` |
| 60 | + - Use proper capitalization and spacing |
| 61 | + |
| 62 | +### 3. Property Structure |
| 63 | +Each parameter must follow this structure: |
| 64 | +```typescript |
| 65 | +{ |
| 66 | + displayName: 'Human Readable Name', |
| 67 | + name: 'parameter_name', |
| 68 | + type: 'string' | 'options' | 'boolean' | 'multiOptions', |
| 69 | + required: false, // true if the value is required, false if not |
| 70 | + default: 'default_value', |
| 71 | + description: 'Clear, helpful description from OpenAPI', |
| 72 | + options: [], // For non-options types, empty array |
| 73 | + displayOptions, |
| 74 | + routing: { |
| 75 | + request: { |
| 76 | + qs: { |
| 77 | + parameter_name: '={{$value}}', |
| 78 | + }, |
| 79 | + }, |
| 80 | + }, |
| 81 | +} |
| 82 | +``` |
| 83 | + |
| 84 | +### 4. Options Array Rules |
| 85 | + |
| 86 | + |
| 87 | +- For enum parameters, create options with proper capitalization: |
| 88 | +```typescript |
| 89 | +options: [ |
| 90 | + { name: 'Desktop', value: 'desktop' }, |
| 91 | + { name: 'Mobile', value: 'mobile' }, |
| 92 | + { name: 'Tablet', value: 'tablet' }, |
| 93 | +] |
| 94 | +``` |
| 95 | +- The options must be correctly sorted in alphabetic order |
| 96 | +- And the names must always be human readable |
| 97 | + |
| 98 | +### 5. Required Parameters |
| 99 | +- Skip `api_key` and `engine` parameters (handled by node framework) |
| 100 | +- Mark truly required parameters appropriately |
| 101 | +- Use reasonable defaults for optional parameters |
| 102 | + |
| 103 | +### 6. Description Guidelines |
| 104 | +- Use the OpenAPI description as-is but ensure it's clear and helpful |
| 105 | +- Add context about parameter usage when beneficial |
| 106 | +- Include examples or format specifications when provided in OpenAPI |
| 107 | +- Maintain markdown formatting for better readability |
| 108 | + |
| 109 | +### 7. Special Parameter Handling |
| 110 | +- **Location/Geographic**: Use appropriate defaults and clear descriptions |
| 111 | +- **Language/Locale**: Provide comprehensive option lists with proper names |
| 112 | +- **Pagination**: Default to reasonable values (`page: '1'`, `num: '10'`) |
| 113 | +- **Date/Time**: Include format specifications and validation hints |
| 114 | +- **Enum Arrays**: Convert to proper option arrays with human-readable names |
| 115 | + |
| 116 | +### 8. Property Grouping |
| 117 | +- **Collection Type**: Use `'collection'` type to group optional parameters that users can choose to add |
| 118 | +- **Fixed Collection Type**: Use `'fixedCollection'` type to group semantically related parameters |
| 119 | +- Group related parameters by category (e.g., "Search Options", "Pagination", "Location Settings", "Date Filters") |
| 120 | +- Use meaningful group names that describe the parameter category |
| 121 | +- Parameters within the same logical group should use the same `displayOptions` conditions |
| 122 | + |
| 123 | +Example collection structure: |
| 124 | +```typescript |
| 125 | +{ |
| 126 | + displayName: 'Search Options', |
| 127 | + name: 'searchOptions', |
| 128 | + type: 'collection', |
| 129 | + placeholder: 'Add Search Option', |
| 130 | + default: {}, |
| 131 | + options: [ |
| 132 | + // Related parameters go here |
| 133 | + ], |
| 134 | + displayOptions, |
| 135 | +} |
| 136 | +``` |
| 137 | + |
| 138 | +### 9. Engine Name Conventions |
| 139 | +- Use snake_case for the engine value (e.g., `google_search`, `bing_news`) |
| 140 | +- Use Title Case for the display name (e.g., `Google Search`, `Bing News`) |
| 141 | +- Ensure the engine name matches the OpenAPI operationId or endpoint purpose |
| 142 | + |
| 143 | +## Quality Checklist |
| 144 | +Before finalizing, ensure: |
| 145 | +- [ ] All parameter names are human-readable |
| 146 | +- [ ] All enum options are properly capitalized |
| 147 | +- [ ] Default values are sensible and useful |
| 148 | +- [ ] Descriptions are clear and informative |
| 149 | +- [ ] TypeScript syntax is correct |
| 150 | +- [ ] Import statements are included |
| 151 | +- [ ] Export structure matches the pattern |
| 152 | +- [ ] Required parameters are properly handled |
| 153 | +- [ ] Optional parameters have appropriate defaults |
| 154 | +- [ ] No API keys or sensitive parameters are exposed |
| 155 | +- [ ] Related parameters are grouped using collection or fixedCollection types |
| 156 | +- [ ] Group names are meaningful and descriptive |
| 157 | +- [ ] Parameters within the same group have consistent displayOptions |
| 158 | +- [ ] Run "pnpm lintfix" and fix all errors it does not fix automatically |
| 159 | + |
| 160 | +## Example Transformation |
| 161 | +Given an OpenAPI parameter like: |
| 162 | +```yaml |
| 163 | +device: |
| 164 | + name: device |
| 165 | + in: query |
| 166 | + required: false |
| 167 | + description: "The device type for the search" |
| 168 | + schema: |
| 169 | + type: string |
| 170 | + enum: [desktop, mobile, tablet] |
| 171 | + default: desktop |
| 172 | + x-display-name: "Device Type" |
| 173 | +``` |
| 174 | +
|
| 175 | +Transform to: |
| 176 | +```typescript |
| 177 | +{ |
| 178 | + displayName: 'Device Type', |
| 179 | + name: 'device', |
| 180 | + type: 'options', |
| 181 | + default: 'desktop', |
| 182 | + description: 'The device type for the search', |
| 183 | + options: [ |
| 184 | + { name: 'Desktop', value: 'desktop' }, |
| 185 | + { name: 'Mobile', value: 'mobile' }, |
| 186 | + { name: 'Tablet', value: 'tablet' }, |
| 187 | + ], |
| 188 | + displayOptions, |
| 189 | + routing: { |
| 190 | + request: { |
| 191 | + qs: { |
| 192 | + device: '={{$value}}', |
| 193 | + }, |
| 194 | + }, |
| 195 | + }, |
| 196 | +} |
| 197 | +``` |
| 198 | + |
| 199 | +## Additional Notes |
| 200 | +- Always prioritize user experience with clear, intuitive parameter names |
| 201 | +- Follow n8n's established patterns for consistency |
| 202 | +- Test the generated code for TypeScript compatibility |
| 203 | +- Consider parameter interdependencies and validation |
| 204 | +- Ensure the generated engine integrates seamlessly with the SearchApi node framework |
| 205 | +- Look for .yaml files to get the openapi specs for the engine |
| 206 | + |
| 207 | +Generate the complete TypeScript engine file following these guidelines exactly. |
0 commit comments