pkg/list/list_workflows.go (1)

202-230: Simplify the default case logic.

The default case handles both empty format and "table" format with duplicated string joining logic. This can be simplified to reduce code duplication.

Consider this refactor:

 default:
+    var output strings.Builder
+    output.WriteString(strings.Join(header, delimiter) + utils.GetLineEnding())
+    for _, row := range rows {
+        output.WriteString(strings.Join(row, delimiter) + utils.GetLineEnding())
+    }
+
     // If format is empty or "table", use table format
     if format == "" && term.IsTTYSupportForStdout() {
         // Create a styled table for TTY
         t := table.New().
             // ... existing table configuration ...
             Headers(header...).
             Rows(rows...)
         return t.String() + utils.GetLineEnding(), nil
     }
-    // Default to simple tabular format for non-TTY or when format is explicitly "table"
-    var output strings.Builder
-    output.WriteString(strings.Join(header, delimiter) + utils.GetLineEnding())
-    for _, row := range rows {
-        output.WriteString(strings.Join(row, delimiter) + utils.GetLineEnding())
-    }
     return output.String(), nil

pkg/list/list_values.go (3)

23-31: Consider removing the unused function.

The static analysis tool confirms that getMapKeys is unused. If there's no future usage planned, removing it will reduce clutter.

-// getMapKeys returns a sorted slice of map keys
-func getMapKeys(m map[string]interface{}) []string {
-	keys := make([]string, 0, len(m))
-	for k := range m {
-		keys = append(keys, k)
-	}
-	sort.Strings(keys)
-	return keys
-}

🧰 Tools

🪛 golangci-lint (1.62.2)

24-24: func getMapKeys is unused

(unused)

---

34-324: Refactor the large function.

FilterAndListValues handles multiple steps: filtering stacks, applying queries, formatting output, etc. Splitting it into smaller helper functions would improve readability and maintainability.

---

265-272: Handle CSV field quoting.

Concatenating fields with a plain delimiter can corrupt CSV data if the field itself contains the delimiter or newline. Consider quoting fields for robust CSV output.

pkg/list/list_values_test.go (1)

56-148: Expand test coverage.

You might test nested or array-based query paths to confirm filtering works for complex data structures. It would further validate the code’s resilience.

cmd/list_values.go (2)

35-63: Avoid repeated flag error-handling.

Error-handling for each flag is repeated. Consolidating this into a small helper would reduce duplication and simplify reading.

---

95-116: Evaluate independent command structure.

listVarsCmd sets a single flag before reusing listValuesCmd.Run. This works but might complicate future expansions. Consider a dedicated or unified approach for better clarity.

website/docs/cli/commands/list/list-values.mdx (4)

31-42: Consider enhancing flag documentation with example values.

While the flag descriptions are clear, adding example values would make them more user-friendly.

   <dt><code>--query string</code></dt>
-  <dd>JMESPath query to filter values (e.g., ".vars" to show only variables)</dd>
+  <dd>JMESPath query to filter values (e.g., ".vars" to show only variables, ".config.vpc" to show VPC configuration)</dd>
   <dt><code>--format string</code></dt>
-  <dd>Output format: `table`, `json`, `csv`, `tsv` (default "`table`")</dd>
+  <dd>Output format: `table`, `json`, `csv`, `tsv` (default "`table`"). Example: --format=json</dd>

---

58-58: Replace TODO placeholder with actual JMESPath query examples.

The placeholder needs to be replaced with practical JMESPath query examples to help users understand how to filter values effectively.

Would you like me to help generate some practical JMESPath query examples? Here's a suggestion:

-TODO: define more outputs
+# Show only networking configuration
+atmos list values vpc --query ".config.networking"
+
+# Filter for specific environment variables
+atmos list values vpc --query ".vars | [?contains(name, 'ENV')]"
+
+# Show components with specific tags
+atmos list values vpc --query ".metadata.tags"

---

86-86: Add example command output to enhance documentation.

Replace the TODO with actual command output to help users understand what to expect.

Would you like me to help generate an example output? Here's a suggestion:

-TODO: define example output
+Component: vpc
+
+┌─────────────┬──────────────┬──────────────┬──────────────┐
+│    Key      │   dev-ue1    │  staging-ue1 │   prod-ue1   │
+├─────────────┼──────────────┼──────────────┼──────────────┤
+│ cidr_block  │ 10.0.0.0/16  │ 10.1.0.0/16  │ 10.2.0.0/16  │
+│ enable_flow │    true      │    true      │    true      │
+│ max_azs     │     3        │     3        │     3        │
+└─────────────┴──────────────┴──────────────┴──────────────┘

---

91-92: Enhance typography in related commands section.

Replace hyphens with em dashes for better readability.

-[atmos list components](/cli/commands/list/component) - List available components
-[atmos describe component](/cli/commands/describe/component) - Show detailed information about a component
+[atmos list components](/cli/commands/list/component) — List available components
+[atmos describe component](/cli/commands/describe/component) — Show detailed information about a component

🧰 Tools

🪛 LanguageTool

[typographical] ~91-~91: To join two clauses or introduce examples, consider using an em dash.
Context: ...omponents](/cli/commands/list/component) - List available components - [atmos descr...

(DASH_RULE)

---

[typographical] ~92-~92: To join two clauses or introduce examples, consider using an em dash.
Context: ...onent](/cli/commands/describe/component) - Show detailed information about a compon...

(DASH_RULE)

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

cmd/cmd_utils.go (2)

759-761: Return an error or log when componentName is empty

Currently, returning false without context might make debugging difficult. Consider logging or returning an error to inform callers when componentName is empty.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 758-761: cmd/cmd_utils.go#L758-L761
Added lines #L758 - L761 were not covered by tests

---

768-772: Provide context for DescribeStacks errors

Rather than returning false silently, consider logging or returning the underlying error from ExecuteDescribeStacks to surface potential misconfiguration or retrieval issues.

pkg/list/utils/utils.go (2)

9-13: Consider using errors.As for improved error checks

Directly asserting with err.(*errors.NoValuesFoundError) might be replaced by errors.As(err, &target) for greater flexibility if the error is wrapped in the future.

---

22-24: Simplify the condition

Use a direct return in the condition:

- if newlineCount <= 4 {
-     return true
- }
- return false
+ return newlineCount <= 4

🧰 Tools

🪛 GitHub Check: golangci-lint

[failure] 22-22:
S1008: should use 'return newlineCount <= 4' instead of 'if newlineCount <= 4 { return true }; return false'

cmd/list_settings.go (4)

57-67: Validate defaulting to “settings” component

setupSettingsOptions hardcodes Component: "settings". If new component types need referencing, ensure this remains correct or configurable.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 57-67: cmd/list_settings.go#L57-L67
Added lines #L57 - L67 were not covered by tests

---

71-76: Add coverage for logNoSettingsFoundMessage

A small test verifying console output or logging behavior around missing settings would increase confidence in this path.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 71-76: cmd/list_settings.go#L71-L76
Added lines #L71 - L76 were not covered by tests

---

93-97: Enforce CSV delimiter only if truly CSV

Auto-switching the delimiter is convenient, but be cautious if a user explicitly sets a custom TSV delimiter that matches the default. Document or verify this edge case.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 93-97: cmd/list_settings.go#L93-L97
Added lines #L93 - L97 were not covered by tests

---

111-134: Validate unified stack retrieval

getStacksMapForSettings replicates logic in other commands. If you intend consistent behavior across commands, consider centralizing stack retrieval to reduce duplication.

cmd/list_metadata.go (3)

56-73: Confirm default .metadata usage

setupMetadataOptions defaults query to .metadata. If a user intends to query deeper metadata paths, ensure no conflicts arise from resetting an empty query.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 57-61: cmd/list_metadata.go#L57-L61
Added lines #L57 - L61 were not covered by tests

---

[warning] 63-72: cmd/list_metadata.go#L63-L72
Added lines #L63 - L72 were not covered by tests

---

114-121: Return consistent typed errors

While a QueryError is returned, other code returns wrapped static errors. Ensuring uniform patterns across commands clarifies error handling.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 114-121: cmd/list_metadata.go#L114-L121
Added lines #L114 - L121 were not covered by tests

🪛 GitHub Check: golangci-lint

[failure] 114-114:
function-length: maximum number of lines per function exceeded; max 60 but got 62

---

171-174: Add coverage to no-output scenario

The final check for empty or minimal table output is untested. Write a quick scenario to confirm correct behavior when no metadata is returned.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 171-174: cmd/list_metadata.go#L171-L174
Added lines #L171 - L174 were not covered by tests

cmd/list_values.go (2)

55-57: Consider using static wrapped errors for improved consistency.

Instead of inline error messages, define static errors to wrap them for clarity.

For example:

-if len(args) != 1 {
-  return fmt.Errorf("invalid arguments: the command requires one argument 'component'")
+if len(args) != 1 {
+  return fmt.Errorf("%w: the command requires one argument 'component'", ErrComponentNameRequired)
}

🧰 Tools

🪛 GitHub Check: golangci-lint

[failure] 56-56:
do not define dynamic errors, use wrapped static errors instead: "fmt.Errorf("invalid arguments: the command requires one argument 'component'")"

---

205-205: End comment with a period.

For clarity and consistency with the codebase style, add a period at the end of the comment on line 205.

🧰 Tools

🪛 GitHub Check: golangci-lint

[failure] 205-205:
Comment should end in a period

pkg/list/list_values.go (2)

66-97: Consider extracting sub-steps to smaller helper functions.

The FilterAndListValues function’s responsibilities—extracting, filtering, querying, and formatting—could be decomposed into smaller, more specific helpers. This would enhance maintainability.

---

163-197: Clarify "select" usage in YQ expression for KeySettings.

Using select(.settings // .terraform.settings // .components.terraform.*.settings) can be fragile if additional nested keys are later introduced. Consider a more explicit or parameterized approach.

pkg/list/format/delimited.go (1)

69-77: Remove redundant break statements.

In Go, break after each case is implicit. These breaks can be removed without altering logic, aligning with gosimple S1023.

-    break
...
-    break

🧰 Tools

🪛 golangci-lint (1.64.8)

[error] 69-69: S1023: redundant break statement

(gosimple)

---

[error] 73-73: S1023: redundant break statement

(gosimple)

---

[error] 77-77: S1023: redundant break statement

(gosimple)

🪛 GitHub Check: golangci-lint

[failure] 69-69:
S1023: redundant break statement

---

[failure] 73-73:
S1023: redundant break statement

---

[failure] 77-77:
S1023: redundant break statement

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

Learnt from: aknysh
PR: cloudposse/atmos#810
File: internal/exec/terraform_utils.go:40-213
Timestamp: 2025-03-27T21:06:28.283Z
Learning: In the context of the Atmos project, it's acceptable for functions like `execTerraformOutput` to remain as single functions if they perform a single purpose, such as retrieving Terraform outputs for a component in a stack, even if the function is lengthy.

Learnt from: osterman
PR: cloudposse/atmos#1036
File: cmd/list_settings.go:46-50
Timestamp: 2025-03-27T21:06:28.284Z
Learning: In the Atmos project, -1 is used as a special value to denote unlimited columns in table outputs, following common software conventions.

cmd/list_errors_test.go (2)

68-69: Merge variable declaration with assignment.

These lines trigger a lint warning (S1021). Merging them improves readability and conforms to idiomatic Go:

-	var mockRunFunc func(cmd *cobra.Command, args []string) (string, error)
-	mockRunFunc = tc.runFunc
+	mockRunFunc := tc.runFunc

🧰 Tools

🪛 golangci-lint (1.64.8)

[error] 68-68: S1021: should merge variable declaration with assignment on next line

(gosimple)

🪛 GitHub Check: golangci-lint

[failure] 68-68:
S1021: should merge variable declaration with assignment on next line

---

170-171: Merge variable declaration with assignment again.

Same lint issue (S1021) appears here. Merge these lines as well for consistency:

-	var mockRunFunc func(cmd *cobra.Command, args []string) (string, error)
-	mockRunFunc = tc.runFunc
+	mockRunFunc := tc.runFunc

🧰 Tools

🪛 golangci-lint (1.64.8)

[error] 170-170: S1021: should merge variable declaration with assignment on next line

(gosimple)

🪛 GitHub Check: golangci-lint

[failure] 170-170:
S1021: should merge variable declaration with assignment on next line

cmd/list_metadata.go (3)

22-41: Add higher-level tests for RunE execution.

These lines invoke listMetadata in the RunE function. Consider adding an integration-style test for the Cobra command to confirm behavior and capture coverage for lines 32-40.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 32-37: cmd/list_metadata.go#L32-L37
Added lines #L32 - L37 were not covered by tests

---

[warning] 39-40: cmd/list_metadata.go#L39-L40
Added lines #L39 - L40 were not covered by tests

---

56-73: Consider testing setupMetadataOptions.

A small unit test verifying the resulting query, format, and stack pattern would ensure changes here remain robust.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 57-61: cmd/list_metadata.go#L57-L61
Added lines #L57 - L61 were not covered by tests

---

[warning] 63-72: cmd/list_metadata.go#L63-L72
Added lines #L63 - L72 were not covered by tests

---

119-167: Refine error handling and coverage.

While listMetadata nicely differentiates error types, lines 119-167 exhibit partial coverage according to codecov warnings. Adding more direct tests (or command-level tests) would confirm the correct reporting of each error scenario.

Do you want me to open a new issue or provide a test suite for these uncovered lines?

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 119-123: cmd/list_metadata.go#L119-L123
Added lines #L119 - L123 were not covered by tests

---

[warning] 126-130: cmd/list_metadata.go#L126-L130
Added lines #L126 - L130 were not covered by tests

---

[warning] 132-135: cmd/list_metadata.go#L132-L135
Added lines #L132 - L135 were not covered by tests

---

[warning] 139-143: cmd/list_metadata.go#L139-L143
Added lines #L139 - L143 were not covered by tests

---

[warning] 145-158: cmd/list_metadata.go#L145-L158
Added lines #L145 - L158 were not covered by tests

---

[warning] 161-164: cmd/list_metadata.go#L161-L164
Added lines #L161 - L164 were not covered by tests

---

[warning] 166-166: cmd/list_metadata.go#L166
Added line #L166 was not covered by tests

pkg/list/format/table.go (2)

187-213: High complexity in Format.

Lines 187-213 incorporate multiple checks (TTY, width calculations, etc.). Consider splitting responsibilities into smaller helper functions to reduce complexity.

---

205-207: Potential static error usage.

This dynamic error is consistent with your approach, but you could wrap ErrTableTooWide with %w for consistent error inspection—particularly if you wish to differentiate table-width issues from other errors.

-	return "", errors.Errorf("%s (width: %d > %d).",
-		ErrTableTooWide.Error(), estimatedWidth, terminalWidth)
+	return "", fmt.Errorf("%w (width: %d > %d).",
+		ErrTableTooWide, estimatedWidth, terminalWidth)

cmd/list_values.go (2)

206-207: Add period to comment.

Static analysis indicates this comment should end with a period for consistency with other comments.

-// logNoValuesFoundMessage logs an appropriate message when no values or vars are found
+// logNoValuesFoundMessage logs an appropriate message when no values or vars are found.

🧰 Tools

🪛 GitHub Check: golangci-lint

[failure] 206-206:
Comment should end in a period

---

215-291: Function exceeds recommended length.

The listValues function is 75 lines long, exceeding the 60-line limit. Consider refactoring into smaller functions for better readability and maintainability.

You could split this function into several smaller functions:

1. A function to validate arguments
2. A function to initialize config and check component existence
3. A function to process stacks and apply filters

Example refactoring approach:

func listValues(cmd *cobra.Command, args []string) (string, error) {
    // Ensure we have a component name
    if len(args) == 0 {
        return "", ErrComponentNameRequired
    }
    componentName := args[0]

    // Get all flags and options
    filterOptions, processingFlags, err := getListValuesFlags(cmd)
    if err != nil {
        return "", err
    }

    // Configure component filtering options
    configureComponentFiltering(filterOptions, componentName)

+   // Initialize config and validate component
+   stacksMap, err := initConfigAndValidateComponent(componentName, processingFlags)
+   if err != nil {
+       return "", err
+   }
    
-   // Use ComponentFilter instead of Component for filtering by component name
-   // This allows the extractComponentValues function to handle it properly
-   filterOptions.ComponentFilter = componentName
-
-   // For vars command (using .vars query), we clear the Component field
-   // to let the system determine the correct query path
-   if filterOptions.Query == ".vars" {
-       // Using ComponentFilter with empty Component
-       // lets the system build the correct YQ expression
-       filterOptions.Component = ""
-   } else {
-       // For other cases where we're not querying vars, use the standard approach
-       filterOptions.Component = componentName
-   }
-
-   // Log the component name
-   log.Debug("Processing component",
-       "component", componentName,
-       "component_field", filterOptions.Component,
-       "component_filter", filterOptions.ComponentFilter)
-
-   // Initialize CLI config
-   configAndStacksInfo := schema.ConfigAndStacksInfo{}
-   atmosConfig, err := config.InitCliConfig(configAndStacksInfo, true)
-   if err != nil {
-       return "", fmt.Errorf(ErrFmtWrapErr, ErrInitializingCLIConfig, err)
-   }
-
-   // Check if the component exists
-   if !checkComponentExists(&atmosConfig, componentName) {
-       return "", &listerrors.ComponentDefinitionNotFoundError{Component: componentName}
-   }
-
-   // Get all stacks
-   stacksMap, err := e.ExecuteDescribeStacks(atmosConfig, "", nil, nil, nil, false, processingFlags.Templates, processingFlags.Functions, false, nil)
-   if err != nil {
-       return "", fmt.Errorf(ErrFmtWrapErr, ErrDescribingStacks, err)
-   }

+   // Process and filter values
+   return processAndFilterValues(stacksMap, filterOptions, componentName, processingFlags)
}

+// configureComponentFiltering sets up the component filtering options
+func configureComponentFiltering(filterOptions *l.FilterOptions, componentName string) {
+   filterOptions.ComponentFilter = componentName
+
+   if filterOptions.Query == ".vars" {
+       // Using ComponentFilter with empty Component
+       // lets the system build the correct YQ expression
+       filterOptions.Component = ""
+   } else {
+       // For other cases where we're not querying vars, use the standard approach
+       filterOptions.Component = componentName
+   }
+
+   // Log the component name
+   log.Debug("Processing component",
+       "component", componentName,
+       "component_field", filterOptions.Component,
+       "component_filter", filterOptions.ComponentFilter)
+}
+
+// initConfigAndValidateComponent initializes the CLI config and validates the component exists
+func initConfigAndValidateComponent(componentName string, processingFlags *fl.ProcessingFlags) (map[string]interface{}, error) {
+   // Initialize CLI config
+   configAndStacksInfo := schema.ConfigAndStacksInfo{}
+   atmosConfig, err := config.InitCliConfig(configAndStacksInfo, true)
+   if err != nil {
+       return nil, fmt.Errorf(ErrFmtWrapErr, ErrInitializingCLIConfig, err)
+   }
+
+   // Check if the component exists
+   if !checkComponentExists(&atmosConfig, componentName) {
+       return nil, &listerrors.ComponentDefinitionNotFoundError{Component: componentName}
+   }
+
+   // Get all stacks
+   stacksMap, err := e.ExecuteDescribeStacks(atmosConfig, "", nil, nil, nil, false, processingFlags.Templates, processingFlags.Functions, false, nil)
+   if err != nil {
+       return nil, fmt.Errorf(ErrFmtWrapErr, ErrDescribingStacks, err)
+   }
+
+   return stacksMap, nil
+}
+
+// processAndFilterValues applies filtering and formatting to component values
+func processAndFilterValues(stacksMap map[string]interface{}, filterOptions *l.FilterOptions, componentName string, processingFlags *fl.ProcessingFlags) (string, error) {
+   // Log the filter options
+   log.Debug("Filtering values",
+       "component", componentName,
+       "componentFilter", filterOptions.ComponentFilter,
+       "query", filterOptions.Query,
+       "includeAbstract", filterOptions.IncludeAbstract,
+       "maxColumns", filterOptions.MaxColumns,
+       "format", filterOptions.FormatStr,
+       "stackPattern", filterOptions.StackPattern,
+       "processTemplates", processingFlags.Templates,
+       "processYamlFunctions", processingFlags.Functions)
+
+   // Filter and list component values across stacks
+   output, err := list.FilterAndListValues(stacksMap, filterOptions)
+   if err != nil {
+       var noValuesErr *listerrors.NoValuesFoundError
+       if errors.As(err, &noValuesErr) {
+           logNoValuesFoundMessage(componentName, filterOptions.Query)
+           return "", nil
+       }
+       return "", err
+   }
+
+   return output, nil
+}

🧰 Tools

🪛 GitHub Check: golangci-lint

[failure] 215-215:
function-length: maximum number of lines per function exceeded; max 60 but got 75

pkg/list/format/delimited.go (3)

57-79: Simplify the switch case structure in getValueKeysFromStacks.

The function has redundant break statements and could be simplified for better readability.

func getValueKeysFromStacks(data map[string]interface{}, keys []string) []string {
	var valueKeys []string

	for _, stackName := range keys {
		stackData := data[stackName]

		switch typedData := stackData.(type) {
		case map[string]interface{}:
			if varsData, ok := typedData["vars"].(map[string]interface{}); ok {
				for k := range varsData {
					valueKeys = append(valueKeys, k)
				}
-				break
			} else {
+				// If no vars map found, use top-level keys
+				for k := range typedData {
+					valueKeys = append(valueKeys, k)
+				}
			}
-
-			for k := range typedData {
-				valueKeys = append(valueKeys, k)
-			}

		case []interface{}, nil:
			valueKeys = []string{ValueKey}

		default:
			valueKeys = []string{ValueKey}
		}

		if len(valueKeys) > 0 {
			break
		}
	}
	sort.Strings(valueKeys)
	return valueKeys
}

---

112-121: Add comment to explain case handling in generateValueKeyRows.

The switch case differentiates between maps with value keys and other types. Adding a comment would improve readability.

switch typedData := stackData.(type) {
case map[string]interface{}:
+   // If the map has a ValueKey entry, use that specific value
+   // Otherwise format the entire map
    if val, ok := typedData[ValueKey]; ok {
        value = formatValue(val)
    } else {
        value = formatValue(typedData)
    }
default:
+   // For non-map types, format the entire value
    value = formatValue(stackData)
}

---

186-204: Enhance error handling in formatValue.

When JSON marshaling fails, more context would help with debugging. Consider logging the error or providing more details in the fallback string.

func formatValue(value interface{}) string {
	switch v := value.(type) {
	case string:
		return v
	case []interface{}:
		var values []string
		for _, item := range v {
			values = append(values, fmt.Sprintf("%v", item))
		}
		return strings.Join(values, ",")
	case map[string]interface{}:
		jsonBytes, err := json.Marshal(v)
		if err != nil {
-			return fmt.Sprintf("%v", v)
+			// Provide fallback with error context
+			return fmt.Sprintf("Error marshaling JSON: %v, Raw: %v", err, v)
		}
		return string(jsonBytes)
	default:
		return fmt.Sprintf("%v", v)
	}
}

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

pkg/list/utils/utils.go (1)

27-69: Component existence checking needs optimization.

The function correctly checks if a component exists across stacks, but there are several areas for improvement:

1. The implementation only checks for terraform components, ignoring other potential component types
2. The code makes multiple type assertions without detailed error handling
3. Using ExecuteDescribeStacks is expensive for just checking component existence

Consider using a more efficient approach by directly accessing component configuration instead of running the describe stacks command, and add support for other component types:

func CheckComponentExists(atmosConfig *schema.AtmosConfiguration, componentName string) bool {
	if componentName == "" {
		return false
	}

	// Extract component name from path if needed
	parts := strings.Split(componentName, "/")
	baseName := parts[len(parts)-1]

-	// Get all stacks to check for the component
-	stacksMap, err := e.ExecuteDescribeStacks(*atmosConfig, "", nil, nil, nil, false, false, false, false, nil)
-	if err != nil {
-		return false
-	}
-
-	// Process all stacks to find the component
-	for _, stackData := range stacksMap {
-		stackMap, ok := stackData.(map[string]interface{})
-		if !ok {
-			continue
-		}
-
-		componentsMap, ok := stackMap["components"].(map[string]interface{})
-		if !ok {
-			continue
-		}
-
-		terraformComponents, ok := componentsMap["terraform"].(map[string]interface{})
-		if !ok {
-			continue
-		}
-
-		// Check if the component exists in this stack
-		_, exists := terraformComponents[baseName]
-		if exists {
-			return true
-		}
-	}
+	// Get component manifests directly
+	componentManifests, err := atmosConfig.GetComponentManifests("")
+	if err != nil {
+		return false
+	}
+	
+	// Check if component exists in any stack
+	for _, manifest := range componentManifests {
+		// Check across different component types (terraform, helmfile, etc.)
+		for _, componentType := range manifest.ComponentTypes {
+			components, ok := manifest.Components[componentType]
+			if !ok {
+				continue
+			}
+			
+			if _, exists := components[baseName]; exists {
+				return true
+			}
+		}
+	}

	return false
}

Note: This suggested implementation assumes the existence of a GetComponentManifests method and appropriate structure in the AtmosConfiguration. Adjust according to the actual API available.

cmd/list_settings.go (2)

58-69: Consider extracting "settings" as a constant.

Defining a constant like KeySettings = "settings" (similar to KeyMetadata) in a shared package improves consistency and future maintainability.

-func setupSettingsOptions(commonFlags fl.CommonFlags, componentFilter string) *l.FilterOptions {
-	return &l.FilterOptions{
-		Component:       "settings",
+const KeySettings = "settings"

+func setupSettingsOptions(commonFlags fl.CommonFlags, componentFilter string) *l.FilterOptions {
+	return &l.FilterOptions{
+		Component:       KeySettings,
		ComponentFilter: componentFilter,
		// ...
	}
}

---

88-93: Align error handling with similar commands.

Here, &listerrors.CommonFlagsError{Cause: err} is used, whereas the metadata command uses a different error type for failing to retrieve common flags. For consistency, consider using a uniform error approach across commands.

cmd/list_metadata.go (2)

95-101: Standardize error types for common flags retrieval.

Here, QueryError is used to wrap errors from fl.GetCommonListFlags. In list_settings.go, a different error type is used for the same scenario. Adopting one uniform error type simplifies debugging.

---

155-161: Consider logging the exact query.

When logging “No metadata found,” including the resolved query in the message can help troubleshoot filtered outputs.

 if errors.As(err, &noValuesErr) {
-    logNoMetadataFoundMessage(params.ComponentFilter)
+    log.Info(fmt.Sprintf("No metadata found for component '%s' with query '%s'", params.ComponentFilter, params.CommonFlags.Query))
     return "", nil
 }

cmd/list_values.go (3)

57-59: Remove redundant argument check in RunE.

cobra.ExactArgs(1) already ensures that exactly one argument is provided. The explicit check here duplicates that behavior.

-	if len(args) != 1 {
-		return ErrInvalidArguments
-	}

---

273-275: Remove unreachable error scenario.

Because Args: cobra.ExactArgs(1) is enforced, this condition won't occur at runtime. Streamline the code by removing it.

-func listValues(cmd *cobra.Command, args []string) (string, error) {
-	if len(args) == 0 {
-		return "", ErrComponentNameRequired
-	}
+func listValues(cmd *cobra.Command, args []string) (string, error) {

---

248-269: Refactor repeated stack initialization logic.

This logic mirrors similar commands (listSettings, listMetadata). Extracting a shared helper function for "init config + describe stacks + check component" could DRY the code.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

Learnt from: aknysh
PR: cloudposse/atmos#810
File: internal/exec/terraform_utils.go:40-213
Timestamp: 2025-03-27T21:06:28.283Z
Learning: In the context of the Atmos project, it's acceptable for functions like `execTerraformOutput` to remain as single functions if they perform a single purpose, such as retrieving Terraform outputs for a component in a stack, even if the function is lengthy.

Learnt from: osterman
PR: cloudposse/atmos#1036
File: cmd/list_settings.go:46-50
Timestamp: 2025-03-27T21:06:28.284Z
Learning: In the Atmos project, -1 is used as a special value to denote unlimited columns in table outputs, following common software conventions.

website/docs/cli/commands/list/list-values.mdx (2)

112-136: Helpful Nested Object Display Instructions
The section on handling nested objects is clear, providing both guidance and an example JSON output.

Consider using a typographical ellipsis (… instead of three dots) in placeholders (e.g., {...}) if it aligns with your documentation style guidelines.

🧰 Tools

🪛 LanguageTool

[style] ~116-~116: Consider using the typographical ellipsis character here instead.
Context: ... table format, nested objects appear as {...} placeholders 2. Use --format json o...

(ELLIPSIS)

---

137-141: Related Commands Enhance Navigation
Listing related commands is beneficial for users looking to explore further functionalities.

For improved readability, consider using an em dash (—) instead of a hyphen to join the command link with its description. For example:

• [atmos list components](/cli/commands/list/components) — List available components
• [atmos describe component](/cli/commands/describe/component) — Show detailed information about a component

🧰 Tools

🪛 LanguageTool

[typographical] ~139-~139: To join two clauses or introduce examples, consider using an em dash.
Context: ...mponents](/cli/commands/list/components) - List available components - [atmos descr...

(DASH_RULE)

---

[typographical] ~140-~140: To join two clauses or introduce examples, consider using an em dash.
Context: ...onent](/cli/commands/describe/component) - Show detailed information about a compon...

(DASH_RULE)

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro