henriqueinonhe/eslint-plugin-next-auth0

Rules enforcing best practices when using Auth0's NextJS SDK.

eslint-plugin-next-auth0

TODO

Installation

You'll first need to install ESLint:

npm i eslint --save-dev

Next, install eslint-plugin-next-auth0:

npm install eslint-plugin-next-auth0 --save-dev

Usage

Add next-auth0 to the plugins section of your .eslintrc configuration file. You can omit the eslint-plugin- prefix:

{
  "plugins": ["next-auth0"]
}

Then configure the rules you want to use under the rules section.

{
  "rules": {
    "next-auth0/rule-name": 2
  }
}

Rules

TODO: Run eslint-doc-generator to generate the rules list.

eslint-plugin-next-auth0's Issues

[no-auth-route-cst] Add support for template strings

Right now, we can only catch usages of string literals. However, the auth routes will usually be template strings due to query params and that kind of stuff (e.g.: router.push(`/api/auth/login?${someQueryParams}`))

We should also catch that kind of navigation 🧐

[no-auth-route-cst] Add support for route strings in variables with narrowed types

If one were to use a CST with the route in a variable, there would be 2 cases for us:

1. Their variable has a wide string type:

const getAuthRoute: () => string = () => { /* ... */ };

const route = getAuthRoute();
//       ^ type: string

router.push(route);

2. The variable is declared in a way that allows typescript to narrow its type:

const route = isSignUpNeeded ? '/api/auth/login' :  '/api/auth/signup';
//       ^ type: '/api/auth/login' || '/api/auth/signup'

router.push(route);

For case 1, we can't do anything about it. The string value is a runtime-only information and we can't get that 🤷🏽 However, for case 2, by using eslint's typescript parser, we'll have a finite set of values for the navigation call argument and we can enforce no-auth-route-cst.

Create proper README file

We need to create a README that contains at least:

• An explanation of why this exists
• How to install it
• What rules exist, why they are needed and some examples of failing and passing code

[no-auth-route-cst] Add support for any router variable name

Right now, we're only checking for next navigation methods called in a variable named router. However, that may not always be the case. Someone could do

const routyMcRouterFace = useRouter();

routyMcRouterFace.push('/api/auth/login');

and no-auth-route-cst wouldn't catch it. We need to support any variable name that is a next router to enforce the rule.

Migrate repo to Typescript

Add a license

If the world was a nice place, i would like to use the GPLv3 😶‍🌫️ However, as that is usually a hindrance for open source tools, maybe we could use the MIT one, as eslint itself uses? 🤔

Organize tests properly

[no-auth-route-cst] Add proper error message

Right now, we only have a placeholder message when we the rule fails. We should add a proper message explaining why we can't use CST for auth routes, if possible.

[no-auth-route-cst] Add support for destructured router navigation methods

Right now, we're only checking for next navigation methods called as a member of a variable. However, that may not always be the case. Someone could do

const { push } = useRouter();

push('/api/auth/login');

and no-auth-route-cst wouldn't catch it. We need to check that some function variable is a next router navigation method to enforce the rule on it.