The condition resolve(configOrPath) !== resolve(cwd) has a logical flaw. When configOrPath is a custom config file path like './uno.config.custom.ts' and cwd is the current working directory (e.g., /home/user/project), resolve(configOrPath) will resolve to /home/user/project/uno.config.custom.ts, while resolve(cwd) will be /home/user/project. These will never be equal, so this condition will always be true for file paths.

However, this means the error will be thrown even when the config path happens to equal the current working directory, which could occur in edge cases. The real issue is that this condition doesn't accurately distinguish between "explicit custom config file" vs "default directory". The logic should check whether configOrPath was originally set to process.cwd() by line 26, but that information is lost after reassignment. Consider tracking whether an explicit config file was provided separately.

This is the check for if an explicit config file was provided so I don't really understand, feel free to add actual code suggestions. This was added to fix errors with CLI.

Using console.error for this warning message is inconsistent with the error handling pattern used in the rest of this file. When an explicit custom config file is missing, an Error is thrown (line 40). For consistency, consider whether this should also throw an error, or if both should use a logger interface.

Additionally, the message "Config file not found in ${configOrPath}" is misleading when configOrPath is a directory path (like /home/user/project). It would be clearer to say something like "No config file found in directory ${configOrPath}" or "Using default config - no config file found in ${configOrPath}".

Consistency is not wanted here, if the file is missing without an explicit custom config it's a an error but generally fine to continue with the default config (for now), if the user specified a custom config file but it is missing an error should be thrown because otherwise the defult config would be used instead removing the user's custom configuration.

The changes suggested to the message only shifts the misleading part to when configOrPath is a file.

The condition !isFile && !result.sources?.length will log an error even when no config file was explicitly requested. Consider this scenario: a user calls loadConfig() with default parameters (no explicit configFile), and no default config files exist in the directory. The user gets a console.error message even though they may have intentionally chosen to use only inline configuration.

This differs from the intended behavior described in the PR, which should only warn when looking for a normal config file fails. The code should differentiate between:

1. User explicitly provided a custom config file path → throw error (lines 38-41)
2. User didn't provide a config file, but default search found nothing → log warning (this case)
3. User provided inline config only (configFile: false) → no warning (already handled on line 19-23)

Consider checking whether inlineConfig.configFile was undefined to determine if a config file search was actually intended.

The docs say that using a dedicated uno.config.ts is highly recommended (https://unocss.dev/guide/config-file) so I think it's fine logging a warning if the file doesn't exist.

The error is thrown before the loader attempts to load the config, but the console.error is logged after the loader runs. This creates an inconsistency: when an explicit custom config file is missing, the function throws immediately and never attempts to load anything. However, when the default config search fails, the loader still runs (and fails), but the function continues executing and returns a result with default configuration.

This asymmetry could be confusing. If the intent is to throw for explicit custom configs and warn for default configs, the logic is correct but could benefit from a comment explaining this design decision. However, based on the PR description which says "logs an error when a normal config file is missing", it seems the intent is just to inform, not to change behavior for the default case.

I don't think this is confusing, a user specifically specifying a configFile and it being missing is more serious than a user not specifying any configFile and it being missing. More input is welcome. Also don't agree that behavior is changed for the default case, there is a log but the functionality is the same.

The logic for detecting whether a custom config file was explicitly provided is fragile. The check resolve(configOrPath) !== resolve(cwd) attempts to distinguish between an explicit file path and a directory, but this doesn't account for the code flow:

1. Line 26: If inlineConfig.configFile is falsy, configOrPath is set to process.cwd()
2. Line 12: The default value for configOrPath parameter is also cwd

The code can't distinguish between:

• User passed loadConfig(cwd, cwd) (no custom config)
• User passed loadConfig(cwd, { configFile: './uno.config.ts' }) where the file doesn't exist

A more robust approach would be to track whether inlineConfig.configFile was explicitly set to a string value, rather than trying to infer this from the resolved paths.