What is the best approach to extend the GoogleSheetsV2 node for listing sheets?

Based on best practices for both maintainability and community contributions, here's what I'd suggest:

Consider Extending Rather Than Forking

Rather than copying the entire core node (which can lead to maintenance challenges and diverge from upstream changes), it’s generally preferable to extend or subclass the existing functionality. This has two major advantages:

• Inheritance of Future Changes: By subclassing the core node, your custom node can automatically benefit from improvements or bug fixes in the core functionality.
• Easier Upstream Collaboration: If you later decide to propose the additional feature upstream, your smaller extension might be easier for maintainers to review and integrate.

Recommended Approach: Subclass the Core Node

Create your custom node as a subclass of the existing GoogleSheetsV2 node. In your subclass, add your method for “get the list of sheets” while keeping the core functionality unchanged. This way you keep the extra logic separate without copying the entire node code, for example:

TYPESCRIPTCopied
import { GoogleSheetsV2 } from 'n8n-nodes-base';

export class ExtendedGoogleSheets extends GoogleSheetsV2 {

  async execute(this: IExecuteFunctions): Promise<INodeExecutionData[][]> {
    // If your node is meant for listing sheets, you might introduce a new operation
    const operation = this.getNodeParameter('operation', 0);

    if (operation === 'listSheets') {
      const items = this.getInputData();
      const returnData: INodeExecutionData[] = [];
      
      for (let itemIndex = 0; itemIndex < items.length; itemIndex++) {
        try {
          const spreadsheetId = this.getNodeParameter('spreadsheetId', itemIndex) as string;
          const endpoint = `https://sheets.googleapis.com/v4/spreadsheets/${spreadsheetId}`;
          const qs: IDataObject = { includeGridData: false };

          const response = await this.helpers.requestOAuth2.call(this, 'googleSheetsOAuth2Api', {
            method: 'GET',
            uri: endpoint,
            qs,
            json: true,
          });

          const { sheets } = response;
          if (Array.isArray(sheets)) {
            sheets.forEach((sheet) => {
              const { sheetId, title } = sheet.properties || {};
              returnData.push({
                json: {
                  spreadsheetId,
                  sheetId,
                  title,
                },
              });
            });
          }
        } catch (error) {
          throw new NodeOperationError(
            this.getNode(),
            `Google Sheets API Error: ${(error as Error).message}`,
            { itemIndex },
          );
        }
      }
      return [returnData];
    }
    
    // For other operations, call the parent's execute method.
    return super.execute();
  }
}

Note: The snippet above is a simplified example—you might need to adjust parameters, update the node's description, and include your new operation in the settings.

Alternative Approach

If subclassing turns out to be too cumbersome or conflicts with how core services evolve, using a simple custom node (option 3) as a standalone contribution is a valid option. This is especially useful if you want immediate deployment without the overhead of tracking upstream changes.

Summary

• Subclass the Core Node: This is the most balanced approach. It keeps your extra feature separate, reduces code duplication, and keeps in sync with core updates.
• Standalone Custom Node: Use this if you want a quick-and-dirty solution or if subclassing doesn’t suit your use case.

By following the subclassing route, you address your personal goals (having a working solution) while also creating a cleaner path to contribute back to the community if the maintainers decide to revisit the proposal in the future.