Skip to content

colocate: ignore empty module names #166

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

sjbarag
Copy link

@sjbarag sjbarag commented Jul 10, 2025

When extracting module names with utils::getModuleName, any explicit or implicit import of an 'index' file in a module's directory or one of its parents resolves to an empty string. Since all JS strings begin with an empty string, this is considered a matching module name for a used fragment spread. Subsequent imports are ignored because a module name matches. However, the falsiness of the empty string causes an error to still be reported.

In pathological cases, an empty module name can be imported before the import that correctly matches a used fragment spread. This resulted in a false-positive "must be colocated" error, despite the fact that the required import is in fact present.

Ignore empty module names when looking for imports that satisfy a fragment spread's colocation requirement.

When extracting module names with utils::getModuleName, any explicit or
implicit import of an 'index' file in a module's directory or one of its
parents resolves to an empty string. Since all JS strings begin with an
empty string, this is considered a matching module name for a used
fragment spread. Subsequent imports are ignored because a module name
matches. However, the falsiness of the empty string causes an error to
still be reported.

In pathological cases, an empty module name can be imported _before_ the
import that correctly matches a used fragment spread. This resulted in
a false-positive "must be colocated" error, despite the fact that the
required import is in fact present.

Ignore empty module names when looking for imports that satisfy a
fragment spread's colocation requirement.
@sjbarag
Copy link
Author

sjbarag commented Jul 10, 2025

Not sure what the backwards-compatibility policy is now that v2.0.0 has been released, but this seems like it'd be a pretty simple backport onto the 1.x branch 🙂. I haven't updated to Relay v20 or eslint-plugin-relay 2.0.0 yet, so I'd super appreciate the additional release 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants