Summary
While reviewing AWS CloudWatch logs for the Create-Inc/escher agent's write flow, I found a recurring React DOM warning that appears to trace back to lint guidance laint emits today. Filing this so the team can decide direction.
What I observed
Log group: create-flux-production-worker-logs20241203013541864900000001 (us-east-2, 24h window).
Filter: "non-boolean attribute" "jsx" returned 50 events affecting at least 14 distinct agent-generated apps:
BrandbookPage, ClinicDashboard, Dashboard, DavidBernalPage, EliteNILDashboard,
Home, HooksAestheticsWebsite, LeafScanPage, MarketingPage, MathSolverPage,
RealEstatePortal, ReviewsSection, ShiaGPT, ViralForgeAI
A representative sample:
Warning: Received `true` for a non-boolean attribute `jsx`.
If you want to write it to the DOM, pass a string instead: jsx="true" or jsx={value.toString()}.
at style
at div
at ShiaGPT (/home/user/apps/web/src/app/page.jsx:443:69)
Warning: Received `true` for a non-boolean attribute `global`.
If you want to write it to the DOM, pass a string instead: global="true" or global={value.toString()}.
at style
at div
In other words: every one of these projects renders <style jsx>...</style> (and <style jsx global>), but the project lacks the styled-jsx Babel/SWC transform — so React passes jsx and global straight through as DOM attributes and warns at render time. The apps look like Vite + Vitest projects (apps/web), not Next.js.
Why I think laint is involved
The existing rule no-tailwind-animation-classes (src/rules/no-tailwind-animation-classes.ts) flags animate-* Tailwind classes with this message:
Avoid Tailwind animation classes (animate-*). Use <style jsx global> tags to define animations instead.
And the README's example for that rule literally suggests:
// Good - use style jsx global for animations
<style jsx global>{`
.spinner { animation: spin 1s linear infinite; }
`}</style>
That advice is correct in Next.js (which ships styled-jsx). It is not correct in projects without the styled-jsx transform — which is what we're seeing in the logs. The agent appears to have followed the rule's guidance and produced styled-jsx in non-Next projects.
Possible directions
Any of these would be a valid fix; flagging the trade-offs so we can pick:
-
Soften the message in no-tailwind-animation-classes. Make it neutral about the replacement: "Define animations in a CSS module / global CSS file (or <style jsx global> if your project has styled-jsx configured)." This is the smallest change and removes the prescriptive Next-only advice.
-
Add a new rule no-styled-jsx-in-non-next (or similar). Flag <style jsx> and <style jsx global> in projects that don't list next (or styled-jsx) as a dependency. Requires laint to read the project's package.json once per run — not currently in the architecture, but feasible.
-
Platform-tag a stricter variant. Keep the current rule for web projects that are Next-flavored, and add a sibling rule for non-Next web. Requires us to teach laint the distinction between "web" and "web-next".
Option 1 is low-risk and immediately removes the misleading guidance. Option 2 is higher leverage if we expect the agent to produce non-Next projects often.
Evidence preservation
The filter pattern + log group above can reproduce the data on demand. If useful I can pull a wider time window or pivot by sandbox/project to confirm the affected projects all lack next/styled-jsx in package.json.
Filing this rather than opening a unilateral PR because the right remediation depends on intent — happy to draft whichever direction makes sense.
Summary
While reviewing AWS CloudWatch logs for the Create-Inc/escher agent's write flow, I found a recurring React DOM warning that appears to trace back to lint guidance laint emits today. Filing this so the team can decide direction.
What I observed
Log group:
create-flux-production-worker-logs20241203013541864900000001(us-east-2, 24h window).Filter:
"non-boolean attribute" "jsx"returned 50 events affecting at least 14 distinct agent-generated apps:A representative sample:
In other words: every one of these projects renders
<style jsx>...</style>(and<style jsx global>), but the project lacks the styled-jsx Babel/SWC transform — so React passesjsxandglobalstraight through as DOM attributes and warns at render time. The apps look like Vite + Vitest projects (apps/web), not Next.js.Why I think laint is involved
The existing rule
no-tailwind-animation-classes(src/rules/no-tailwind-animation-classes.ts) flagsanimate-*Tailwind classes with this message:And the README's example for that rule literally suggests:
That advice is correct in Next.js (which ships styled-jsx). It is not correct in projects without the styled-jsx transform — which is what we're seeing in the logs. The agent appears to have followed the rule's guidance and produced styled-jsx in non-Next projects.
Possible directions
Any of these would be a valid fix; flagging the trade-offs so we can pick:
Soften the message in
no-tailwind-animation-classes. Make it neutral about the replacement: "Define animations in a CSS module / global CSS file (or<style jsx global>if your project has styled-jsx configured)." This is the smallest change and removes the prescriptive Next-only advice.Add a new rule
no-styled-jsx-in-non-next(or similar). Flag<style jsx>and<style jsx global>in projects that don't listnext(orstyled-jsx) as a dependency. Requires laint to read the project'spackage.jsononce per run — not currently in the architecture, but feasible.Platform-tag a stricter variant. Keep the current rule for
webprojects that are Next-flavored, and add a sibling rule for non-Next web. Requires us to teach laint the distinction between "web" and "web-next".Option 1 is low-risk and immediately removes the misleading guidance. Option 2 is higher leverage if we expect the agent to produce non-Next projects often.
Evidence preservation
The filter pattern + log group above can reproduce the data on demand. If useful I can pull a wider time window or pivot by sandbox/project to confirm the affected projects all lack
next/styled-jsxinpackage.json.Filing this rather than opening a unilateral PR because the right remediation depends on intent — happy to draft whichever direction makes sense.