chore(cli): improve UX when generating types with mismatched component paths

[rydkvist]

Description
This PR improves the user experience in the types generate flow when the component JSON files are not found due to a path mismatch. Previously, users might hit a vague "file not found" error if:

• Components were pulled with a custom --path, but types generate was run without the same --path.
• Components were pulled with the default path, but types generate was run with a custom --path.

What’s Changed

• Clarified ReadComponentsOptions JSDoc: path is optional, but for types generate it must always match the path used when running components pull.
• Updated error messages in readComponentsFiles to explicitly reference storyblok types generate vs storyblok components pull.
• Added clearer feedback about which directory was checked (e.g., Looked for components in: ...).
• Added a runtime warning when no components.json is found in the resolved path while running types generate.

Notes

• No changes to push components flow.
• Backwards compatible — only improves error communication and developer guidance.

[Copilot]

Pull Request Overview

This PR improves error messaging and user guidance when there's a path mismatch between components pull and types generate commands. The changes focus on providing clearer feedback when component JSON files are not found due to directory path misalignment.

• Enhanced JSDoc documentation for ReadComponentsOptions to clarify path requirements for type generation
• Added a purpose field to distinguish between push-components and types-generate flows
• Improved error messages with context-specific guidance and directory path information

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
packages/cli/src/commands/components/push/constants.ts	Enhanced JSDoc documentation and added purpose field to ReadComponentsOptions interface
packages/cli/src/commands/components/push/actions.ts	Updated readComponentsFiles function with improved error handling and context-specific messaging

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The default value for path should be '.storyblok/components' to match the documented default, not '.storyblok'. This mismatch could cause the function to look in the wrong directory.

Suggested change

	const { from, path = '.storyblok', separateFiles = false, suffix, purpose = 'push-components' } = options;
	const { from, path = '.storyblok/components', separateFiles = false, suffix, purpose = 'push-components' } = options;

[alvarosabu]

blocker:

Hi @rydkvist, this is relevant, I believe, the default path should be .storyblok/components

[rydkvist]

Hey! No, not really, it should not be .storyblok/components

The resolvePath function in line 254, sets .storyblok as the default path if no custom path is passed.

This means if path is undefined, then .storyblok will be set today already.

I personally didn't feel this was clear when working with this piece of code (specifically in the readComponentsFiles function). To make this more explicitly, I went ahead and added the fallback one level above, on readComponentsFiles.

The resolvePath function is generic, it's used in multiple action files, and personally I would make the path parameter a required one, so each action consuming the resolvePath has an intentional path, instead of a default path .storyblok which can be missused and lead to future confusion

---

So basically my goal with this change was to explicitly state that the readComponentsFiles function controls the default path, and not theresolvePath function itself.
So that in the future, when we want to change the default file path for this, we do it on this level and not in the resolvePath level

[rydkvist]

On the other hand, all of the other actions dont have a explicit fallback like I added here. So the proper way to handle this could be to revisit all use cases where resolvePath is used, and decide if we actually want to have a fallback in place, or if we should remove the fallback inside resolvePath and instead have the functions calling resolvePath passing a required path