jenseng / eslint-plugin-remix-react-routes Goto Github PK

We need to add some tests to ensure nothing breaks 😅

For some rules we can just use @typescript-eslint/utils' RuleTester, since they work the same regardless of the context.

For rules that use getRemixContext, we'll likely need integration tests (i.e. a simple Remix app), since the config/routes/paths all affect the behavior of the rules.

GIven links like:

<>
  <Link to={`?name=${value}`} />
  <Link to="/foo#awesome" />
</>

The search params and fragment shouldn't be treated as path segments in the route matching.

Not sure what I'm doing wrong but I did this:

npm install eslint-plugin-remix-react-routes --save-dev

And then edited my .eslintrc.js file created by the "just the basic" npx create-remix.

/** @type {import('eslint').Linter.Config} */
module.exports = {
  extends: [
    "@remix-run/eslint-config",
    "@remix-run/eslint-config/node",
    "plugin:remix-react-routes",
  ],
};

And I get this from eslint:

❯ eslint app

Oops! Something went wrong! :(

ESLint: 8.30.0

ESLint couldn't find the config "plugin:remix-react-routes/recommended" to extend from. Please check that the name of the config is correct.

The config "plugin:remix-react-routes/recommended" was referenced from the config file in "/Users/.../{project}/.eslintrc.js".

If you still have problems, please stop by https://eslint.org/chat/help to chat with the team.

If remove the /recommended I get this:

Oops! Something went wrong! :(

ESLint: 8.30.0

"plugin:remix-react-routes" is invalid syntax for a config specifier.

* If your intention is to extend from a configuration exported from the plugin, add the configuration name after a slash: e.g. "plugin:remix-react-routes/myConfig".
* If this is the name of a shareable config instead of a plugin, remove the "plugin:" prefix: i.e. "remix-react-routes".

"plugin:remix-react-routes" was referenced from the config file in "/Users/.../{project}/.eslintrc.js".

Any idea what I'm doing wrong?

While the current rules work well enough for simple string and template literals, they can hit false positives with other expressions. E.g. consider something like this:

const BASE_URL = "http://example.com";

return <a href={`${BASE_URL}/something`} target="_blank">Some site</a>

This gets incorrectly flagged by use-link-for-routes since it doesn't know what BASE_URL is. While we can't solve every case statically, we probably can solve some basic stuff, e.g. const string literals and the like. We might even be able to leverage @typescript-eslint to resolve const strings that come from elsewhere, since they should be known to the type system.

Thanks for this package! Can't believe I've waited this long to try it.

My package.json is type: module so I'd like to keep my remix.config.js with the .js extension. Right now I'm getting:

Error loading Remix config, remix-react-routes rules will be skipped: Error: Error loading Remix config at /Users/kentcdodds/code/epicweb-dev/epic-stack/remix.config.js
Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/kentcdodds/code/epicweb-dev/epic-stack/remix.config.js from /Users/kentcdodds/code/epicweb-dev/epic-stack/node_modules/@remix-run/dev/dist/config.js not supported.
Instead change the require of remix.config.js in /Users/kentcdodds/code/epicweb-dev/epic-stack/node_modules/@remix-run/dev/dist/config.js to a dynamic import() which is available in all CommonJS modules.

Currently the RemixContext determines whether or not we're in a route at the file level. This is fine if the <Link> usage happens within the default route component, but potentially unsafe if it's used in another component in that module -- it could be exported and used within another route, potentially resulting in broken relative links.

We can probably never make this 100% bulletproof, but it might be good enough if we evaluate the component definition along these lines (specifically when we're in a route module):

• If the current component is a named export, assume it may be used elsewhere, and thus consider relative paths unsafe
• Otherwise (default export, or not explicitly exported), assume it's only used within the route module, and relative paths may be allowed (iff enforceInRouteComponents=false)

Example code:

[email protected]

Expected Behavior:

Does not throw an eslint error

Actual Behavior:

Throws an eslint error

I pinned to the latest out of laziness, could probably support much older versions. Only hard requirements are the readConfig and formatRoutesAsJson imports (and the latter we could reimplement if necessary).

As of 1.12.0, remix (and react-router) can handle absolute URLs in <Link>s, so this is no longer worth linting. We should detect the Remix version and emit a warning if this rule is activated within an app using remix >= 1.12.0

Currently the rules evaluate paths in relation to the route containing the element, as is the case with <Link> by default at runtime; i.e. consider a route hierarchy like so:

• /accounts
  • /$accountId
    • /projects
      • /$projectId

If the /projects route has a <Link to="..">, it will always point to /accounts/$accountId, even if our current path is /accounts/$accountId/projects/$projectId

<Link relative="path"> makes it relative to the current path. So in the example above, that same link with relative="path" would point to /accounts/$accountId/projects when the current path is /accounts/$accountId/projects/$projectId.

We should make the rule aware of that; we can't know what the current path will actually be, so perhaps the rule could ignore such elements by default, but also consider optionally detecting/reporting them based on an option.

In a Remix app, ideally any intra-app links should be done with <Link to> so as to avoid full-page loads.

If I try to make use of this with remix v2.3.1 I get this:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: [email protected]
npm ERR! Found: @remix-run/[email protected]
npm ERR! node_modules/@remix-run/dev
npm ERR!   dev @remix-run/dev@"^2.3.1" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @remix-run/dev@"^1.5.1" from [email protected]
npm ERR! node_modules/eslint-plugin-remix-react-routes
npm ERR!   dev eslint-plugin-remix-react-routes@"^1.0.5" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: @remix-run/[email protected]
npm ERR! node_modules/@remix-run/dev
npm ERR!   peer @remix-run/dev@"^1.5.1" from [email protected]
npm ERR!   node_modules/eslint-plugin-remix-react-routes
npm ERR!     dev eslint-plugin-remix-react-routes@"^1.0.5" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:

Not everything is auto-fixable, but it would be nice to support it for at least the following rules:

• use-link-for-routes - switch to remix equivalents
  • <a> -> <Link>
  • <form> -> <Form reloadDocument>
• no-relative-paths - make the paths absolute
• no-urls - switch to native elements, normalizing/removing attributes as necessary
  • <Link> / <NavLink> -> <a>
  • <Form> (and <fetcher.Form>) -> <form>