Plumeria 19.10

Plumeria v19.10 integrates the lint into the bundler plugins by default. A style error now stops the build with no setup.

1. Lint in the build

The compiler stops only what would break its output, such as a key nested deeper than 16 levels. A misspelled property or a selector like &:hover compiles to nothing, and catching it is the lint's job. Until 19.9 that lint stopped a build only when the build script ran it: plumerialint -- next build.

Now oxlint starts inside the bundler and runs @plumeria/eslint-plugin alongside the compile. It runs with --deny-warnings, so any error or warning fails the build, and the build waits for its result before it exits. A build that passes has passed both:

package.json

{
  "scripts": {
    "build": "next build"
  }
}

Plugin	Lints on
`@plumeria/next-plugin`	`next build`
`@plumeria/unplugin`	`vite build`, a single webpack or Rspack build, a single Rollup or Rolldown build, `farm build`

Development servers and watch builds do not lint. The lint runs in parallel with the compile, so the build time is unchanged.

esbuild and Bun do not say whether a build is a one-off or a watch, so they keep plumerialint -- <build>, with --style-prop when the styling prop is renamed. Elsewhere that script still works, and the lint runs once.

2. The rules it runs

The lint runs the recommended rules and only those: oxlint's own rules are off, and eslint.config.* is not read. oxlint skips the files .gitignore ignores.

A renamed styling prop reaches the lint from styleProp, so the rules that read the styling prop check the prop the compiler transforms.

withoutLogicalProperties and withoutPhysicalProperties now drive the lint too. The plugin option that rewrites one spelling also turns on the rule that reports it:

next.config.ts

export default withPlumeria(nextConfig, { withoutLogicalProperties: true });
// runs @plumeria/no-logical-properties in the build

expand-border-shorthands joins the recommended rules as a warning. It is fixable.

@plumeria/eslint-plugin now depends on oxlint, so plumerialint needs no separate install.

3. If the build fails after upgrading

A project that built through lint reports now fails. Fix them, most of them automatically:

npx plumerialint --fix

Or pass lint: false to build without the lint:

next.config.ts

export default withPlumeria(nextConfig, { lint: false });

See @plumeria/next-plugin and @plumeria/unplugin.

Release notes

19.10.2 (Oct 7, 2026)

The build lint reads the styling prop from styleProp, so no-mixed-styling-props, no-inline-object, no-style-prop-relay, no-unresolved-composition and custom-props-require-import check the prop the compiler transforms instead of classStyle
plumerialint takes the styling prop with --style-prop, or reads settings.plumeria.styleProp from the ESLint config when ESLint is installed
@plumeria/init writes --style-prop into the build script it guards with plumerialint when the styling prop is renamed
@plumeria/init writes a renamed styling prop into the ESLint config as settings.plumeria.styleProp, so the editor checks the same prop the compiler transforms
@plumeria/eslint-plugin/guard exports lintOverrides in place of spellingRules

19.10.1 (Oct 7, 2026)

@plumeria/next-plugin starts the build lint only when the running bin is next, not when any path holds a next directory
@plumeria/eslint-plugin/guard no longer exports GUARD_ENV and SpellingOptions

Known issue: The build lint in this release checks classStyle whatever styleProp names, so a project that renamed the styling prop is linted against the wrong prop. Please use ^19.10.2 or later.

19.10.0 (Oct 7, 2026)

@plumeria/next-plugin and @plumeria/unplugin run @plumeria/eslint-plugin through oxlint alongside a production build and stop it on any error or warning, so no build script is needed
@plumeria/unplugin lints on Vite, webpack, Rspack, Rollup, Rolldown and Farm
withoutLogicalProperties and withoutPhysicalProperties turn on the matching lint rule in that lint
Add the lint option to @plumeria/next-plugin and @plumeria/unplugin to build without the lint
expand-border-shorthands joins the recommended rules as a warning
plumerialint runs the oxlint that @plumeria/eslint-plugin depends on, so oxlint needs no separate install
The lint runs the Plumeria rules only, not oxlint's own default rules, and passes when there is no file to lint
@plumeria/eslint-plugin depends on oxlint 1.87.0
@plumeria/init prefixes the build script with plumerialint -- only on esbuild and Bun, and no longer installs oxlint or asks about border shorthands

Known issue: The build lint in this release checks classStyle whatever styleProp names, so a project that renamed the styling prop is linted against the wrong prop. Please use ^19.10.2 or later.