Closest blocker to being cleared, and the only one that is a decision rather than a capability gap.
Tailwind class ordering currently belongs to eslint-plugin-better-tailwindcss (enforce-consistent-class-order). That was a deliberate choice: the plugin is theme-aware via its stylesheet entry point, and it additionally offers no-unknown-classes. oxfmt has its own sortTailwindcss with a stylesheet option, which the ui repository already used before adopting the shared preset.
What needs to happen
Why it does not unblock removal on its own
Even with this cleared, #1, #2 and #3 keep ESLint in the stack. It is worth doing early regardless: it removes a plugin, speeds up the lint step, and is reversible.
Closest blocker to being cleared, and the only one that is a decision rather than a capability gap.
Tailwind class ordering currently belongs to
eslint-plugin-better-tailwindcss(enforce-consistent-class-order). That was a deliberate choice: the plugin is theme-aware via its stylesheet entry point, and it additionally offersno-unknown-classes. oxfmt has its ownsortTailwindcsswith astylesheetoption, which theuirepository already used before adopting the shared preset.What needs to happen
sortTailwindcssis theme-aware to the same degree, i.e. that it resolves custom utilities from the configured stylesheet rather than only Tailwind's built-in ordering..vuefile.no-unknown-classes, which oxfmt's sorter does not offer. It is currentlyoffin the preset anyway, because repositories still carry legacy hand-written classes, so this may cost nothing.Why it does not unblock removal on its own
Even with this cleared, #1, #2 and #3 keep ESLint in the stack. It is worth doing early regardless: it removes a plugin, speeds up the lint step, and is reversible.