Files
payloadcms/packages/admin-bar
Germán Jabloñski 2a929cf385 chore: fix all lint errors and add mechanisms to prevent them from appearing again (#12401)
I think it's easier to review this PR commit by commit, so I'll explain
it this way:

## Commits
1. [parallelize eslint script (still showing logs results in
serial)](c9ac49c12d):
Previously, `--concurrency 1` was added to the script to make the logs
more readable. However, turborepo has an option specifically for these
use cases: `--log-order=grouped` runs the tasks in parallel but outputs
them serially. As a result, the lint script is now significantly faster.
2. [run pnpm
lint:fix](9c128c276a)
The auto-fix was run, which resolved some eslint errors that were
slipped in due to the use of `no-verify`. Most of these were
`perfectionist` fixes (property ordering) and the removal of unnecessary
assertions. Starting with this PR, this won't happen again in the
future, as we'll be verifying the linter in every PR across the entire
codebase (see commit 7).
3. [fix eslint non-autofixable
errors](700f412a33)
All manual errors have been resolved except for the configuration errors
addressed in commit 5. Most were React compiler violations, which have
been disabled and commented out "TODO" for now. There's also an unused
`use no memo` and a couple of `require` errors.
4. [move react-compiler linter to eslint-config
package](4f7cb4d63a)
To simplify the eslint configuration. My concern was that there would be
a performance regression when used in non-react related packages, but
none was experienced. This is probably because it only runs on .tsx
files.
5. [remove redundant eslint config files and fix
allowDefaultProject](a94347995a)
The main feature introduced by `typescript-eslint` v8 was
`projectService`, which automatically searches each file for the closest
`tsconfig`, greatly simplifying configuration in monorepos
([source](https://typescript-eslint.io/blog/announcing-typescript-eslint-v8#project-service)).
Once I moved `projectService` to `packages/eslint-config`, all the other
configuration files could be easily removed.
I confirmed that pnpm lint still works on individual packages.
The other important change was that the pending eslint errors from
commits 2 and 3 were resolved. That is, some files were giving the
error: "[File] was not found by the project service. Consider either
including it in the tsconfig.json or including it in
allowDefaultProject." Below I copy the explanatory comment I left in the
code:
```ts
// This is necessary because `tsconfig.base.json` defines `"rootDir": "${configDir}/src"`,
// And the following files aren't in src because they aren't transpiled.
// This is typescript-eslint's way of adding files that aren't included in tsconfig.
// See: https://typescript-eslint.io/troubleshooting/typed-linting/#i-get-errors-telling-me--was-not-found-by-the-project-service-consider-either-including-it-in-the-tsconfigjson-or-including-it-in-allowdefaultproject
// The best practice is to have a tsconfig.json that covers ALL files and is used for
// typechecking (with noEmit), and a `tsconfig.build.json` that is used for the build
// (or alternatively, swc, tsup or tsdown). That's what we should ideally do, in which case
// this hardcoded list wouldn't be necessary. Note that these files don't currently go
// through ts, only through eslint.
```

6. [Differentiate errors from warnings in VScode ESLint
Rules](5914d2f48d)
There's no reason to do that. If an eslint rule isn't an error, it
should be disabled or converted to a warning.
7. [Disable skip lint, and lint over the entire repo now that it's
faster](e4b28f1360)
The GitHub action linted only the files that had changed in the PR.
While this seems like a good idea, once exceptions were introduced with
[skip lint], they opened the door to propagating more and more errors.
Often, the linter was skipped, not because someone introduced new
errors, but because they were trying to avoid those that had already
crept in, sometimes accidentally introducing new ones.
On the other hand, `pnpm lint` now runs in parallel (commit 1), so it's
not that slow. Additionally, it runs in parallel with other GitHub
actions like e2e tests, which take much longer, so it can't represent a
bottleneck in CI.
8. [fix lint in next
package](4506595f91)
Small fix missing from commit 5
9. [Merge remote-tracking branch 'origin/main' into
fix-eslint](563d4909c1)
10. [add again eslint.config.js in payload
package](78f6ffcae7)
The comment in the code explains it. Basically, after the merge from
main, the payload package runs out of memory when linting, probably
because it grew in recent PRs. That package will sooner or later
collapse for our tooling, so we may have to split it. It's already too
big.

## Future Actions
- Resolve React compiler violations, as mentioned in commit 3.
- Decouple the `tsconfig` used for typechecking and build across the
entire monorepo (as explained in point 5) to ensure ts coverage even for
files that aren't transpiled (such as scripts).
- Remove the few remaining `eslint.config.js`. I had to leave the
`richtext-lexical` and `next` ones for now. They could be moved to the
root config and scoped to their packages, as we do for example with
`templates/vercel-postgres/**`. However, I couldn't get it to work, I
don't know why.
- Make eslint in the test folder usable. Not only are we not linting
`test` in CI, but now the `pnpm eslint .` command is so large that my
computer freezes. If each suite were its own package, this would be
solved, and dynamic codegen + git hooks to modify tsconfig.base.json
wouldn't be necessary
([related](https://github.com/payloadcms/payload/pull/11984)).
2025-05-19 12:36:40 -03:00
..
2025-03-05 19:14:35 +00:00
2025-03-05 19:14:35 +00:00
2025-03-05 19:14:35 +00:00
2025-05-15 14:39:34 -04:00
2025-03-05 19:14:35 +00:00

Payload Admin Bar

An admin bar for React apps using Payload.

Installation

pnpm i @payloadcms/admin-bar

Basic Usage

import { PayloadAdminBar } from '@payloadcms/admin-bar'

export const App = () => {
  return <PayloadAdminBar cmsURL="https://cms.website.com" collection="pages" id="12345" />
}

Checks for authentication with Payload CMS by hitting the /me route. If authenticated, renders an admin bar with simple controls to do the following:

  • Navigate to the admin dashboard
  • Navigate to the currently logged-in user's account
  • Edit the current collection
  • Create a new collection of the same type
  • Logout
  • Indicate and exit preview mode

The admin bar ships with very little style and is fully customizable.

Dynamic props

With client-side routing, we need to update the admin bar with a new collection type and document id on each route change. This will depend on your app's specific setup, but here are a some common examples:

NextJS

For NextJS apps using dynamic-routes, use getStaticProps:

export const getStaticProps = async ({ params: { slug } }) => {
  const props = {}

  const pageReq = await fetch(
    `https://cms.website.com/api/pages?where[slug][equals]=${slug}&depth=1`,
  )
  const pageData = await pageReq.json()

  if (pageReq.ok) {
    const { docs } = pageData
    const [doc] = docs

    props = {
      ...doc,
      collection: 'pages',
      collectionLabels: {
        singular: 'page',
        plural: 'pages',
      },
    }
  }

  return props
}

Now your app can forward these props onto the admin bar. Something like this:

import { PayloadAdminBar } from '@payloadcms/admin-bar';

export const App = (appProps) => {
  const {
    pageProps: {
      collection,
      collectionLabels,
      id
    }
  } = appProps;

  return (
    <PayloadAdminBar
      {...{
        cmsURL: 'https://cms.website.com',
        collection,
        collectionLabels,
        id
      }}
    />
  )
}

Props

Property Type Required Default Description
cmsURL string true http://localhost:8000 serverURL as defined in your Payload config
adminPath string false /admin routes as defined in your Payload config
apiPath string false /api routes as defined in your Payload config
authCollectionSlug string false 'users' Slug of your auth collection
collectionSlug string true undefined Slug of your collection
collectionLabels { singular?: string, plural?: string } false undefined Labels of your collection
id string true undefined id of the document
logo ReactElement false undefined Custom logo
classNames { logo?: string, user?: string, controls?: string, create?: string, logout?: string, edit?: string, preview?: string } false undefined Custom class names, one for each rendered element
logoProps {[key: string]?: unknown} false undefined Custom props
userProps {[key: string]?: unknown} false undefined Custom props
divProps {[key: string]?: unknown} false undefined Custom props
createProps {[key: string]?: unknown} false undefined Custom props
logoutProps {[key: string]?: unknown} false undefined Custom props
editProps {[key: string]?: unknown} false undefined Custom props
previewProps {[key: string]?: unknown} false undefined Custom props
style CSSProperties false undefined Custom inline style
unstyled boolean false undefined If true, renders no inline style
onAuthChange (user: PayloadMeUser) => void false undefined Fired on each auth change
devMode boolean false undefined If true, fakes authentication (useful when dealing with SameSite cookies)
preview boolean false undefined If true, renders an exit button with your onPreviewExit handler)
onPreviewExit function false undefined Callback for the preview button onClick event)