Improve performance of next dev

[openint-bot]

Important

Improve Next.js dev performance by separating Tailwind CSS compilation and adding concurrent script execution.

• Performance Improvement:
  • Separate Tailwind CSS compilation from PostCSS in global.css to improve Next.js startup performance.
  • Update layout.tsx to import tailwind.css separately.
• Scripts:
  • Modify dev script in apps/web/package.json to use concurrently for running dev:css and dev:next.
  • Add dev:css and dev:next scripts for concurrent execution.
• New Files:
  • Add page.tsx and route.ts in app/perf for performance testing.
• Dependencies:
  • Add concurrently to apps/web/package.json and packages/ui/package.json.
  • Add import-in-the-middle and require-in-the-middle to package.json.

^{This description was created by for 16f67ff. It will automatically update as commits are pushed.}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
openint	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 8, 2025 6:02pm

[recurseml]

✨ No issues found! Your code is sparkling clean! ✨

🗒️ View all ignored comments in this repo

• This export statement is redundant as it appears both in the diff and original source code. Adding it again will cause a duplicate export error. The line should be removed since it already exists in the source code.

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 2379c4f in 1 minute and 29 seconds

More details

• Looked at 118 lines of code in 9 files
• Skipped 1 files when reviewing.
• Skipped posting 17 drafted comments based on config settings.

1. apps/web/.gitignore:55

• Draft comment:
  Ensure that generated tailwind.css is correctly ignored. Is it always generated at project root?
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 40% <= threshold 50%
  The comment is asking the author to ensure that a file is correctly ignored, which violates the rule against asking the author to ensure something. However, it also asks a specific question about the location of the generated file, which could be useful for understanding the context of the change.

2. apps/web/app/global.css:1

• Draft comment:
  Comment explains performance bottleneck; consider removing after tailwind v4 upgrade.
• Reason this comment was not posted:
  Confidence changes required: 40% <= threshold 50%
  None

3. apps/web/app/layout.tsx:1

• Draft comment:
  Ensure 'tailwind.css' is generated and available since global.css import is replaced.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 20% <= threshold 50%
  This comment is asking the author to ensure that a specific file is generated and available due to a change in import. It is not suggesting a specific code change or asking for a test to be written. It seems to be more of a reminder or a check, which violates the rule against asking the author to ensure something is done.

4. apps/web/app/perf/page/page.tsx:1

• Draft comment:
  Simple performance page returning timestamp; verify its usage in production.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

5. apps/web/app/perf/route/route.ts:1

• Draft comment:
  New API route returns timestamp; ensure proper caching if needed for performance.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

6. apps/web/package.json:10

• Draft comment:
  Switching 'dev' to use concurrently for dev:* tasks; verify that both CSS and Next dev tasks start correctly.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50%
  The comment is asking the PR author to verify that both CSS and Next dev tasks start correctly after switching to use 'concurrently'. This falls under the rule of not asking the PR author to ensure the behavior is intended or to double-check things.

7. packages/ui/package.json:8

• Draft comment:
  Removed the explicit build-tailwind step in the 'dev' script; ensure tailwind CSS is built appropriately via separate watching.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

8. apps/web/.gitignore:55

• Draft comment:
  Consider whether using a leading slash (e.g. '/tailwind.css') would be more consistent with other entries. Verify that the compiled CSS file is correctly placed and ignored.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

9. apps/web/app/global.css:1

• Draft comment:
  The comment explains a performance bottleneck. Remember to update or remove this note once Tailwind 4 is in place or an alternative solution is adopted.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

10. apps/web/app/layout.tsx:1

• Draft comment:
  Now importing './tailwind.css' (the compiled output) instead of the raw global.css. Ensure that the build/watch process correctly generates tailwind.css before the app loads.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

11. apps/web/app/perf/page/page.tsx:1

• Draft comment:
  New performance test page using Date.now(). Confirm that this simple implementation meets your testing needs.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

12. apps/web/app/perf/route/route.ts:1

• Draft comment:
  New API route returning a dynamic response. Verify that including Date.now() in production responses is intentional.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

13. apps/web/package.json:10

• Draft comment:
  Switching the 'dev' script to use 'concurrently' along with separate 'dev:css' and 'dev:next' commands is a neat improvement. Ensure that both processes are started as expected.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

14. package.json:62

• Draft comment:
  The additions of 'import-in-the-middle' and 'require-in-the-middle' need a double-check. If they’re only used for development or testing, consider moving them to devDependencies.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

15. packages/ui/package.json:11

• Draft comment:
  The 'dev' script no longer runs 'pnpm build-tailwind' upfront. Ensure that the separate 'dev:tailwind' command is run as part of your development workflow.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50%
  None

16. apps/web/app/global.css:2

• Draft comment:
  Consider replacing the abbreviation 'perf' with 'performance' and 'next.js' with 'Next.js' for clarity and consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  This is a purely stylistic suggestion about the wording in a developer comment. Comments are for developers to leave notes, and common abbreviations like 'perf' are well understood. This isn't affecting code quality or functionality. The comment is about formatting rather than substance.
  Perhaps inconsistent capitalization of product names like Next.js could cause confusion in documentation. Maybe maintaining a consistent style even in comments is important for professionalism.
  While consistency is good, this is an internal developer note about a performance issue, not user-facing documentation. The meaning is perfectly clear with the abbreviations.
  Delete this comment as it's making a trivial stylistic suggestion about informal developer notes that doesn't impact code quality or functionality.

17. apps/web/app/global.css:4

• Draft comment:
  Consider capitalizing 'tailwind' to 'Tailwind' and 'postcss' to 'PostCSS' since these are proper names.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  This is purely a stylistic suggestion about capitalization in a comment block. It doesn't affect functionality, build process, or code quality. Comments are for developer documentation and while proper capitalization is nice, it's not important enough to warrant a PR comment. This falls under the "Do NOT make comments that are obvious or unimportant" rule.
  Maybe maintaining consistent and proper capitalization helps with documentation quality and professionalism? Some teams might have strict documentation standards.
  While proper capitalization is good practice, this is just a quick developer note about performance issues, not formal documentation. The meaning is perfectly clear either way.
  Delete this comment as it's too minor and doesn't affect code quality or functionality. It's just about capitalization in an informal comment.

Workflow ID: wflow_9aVAeOVGfxY2is9o

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 16f67ff in 1 minute and 1 seconds

More details

• Looked at 10 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 4 drafted comments based on config settings.

1. apps/web/app/layout.tsx:1

• Draft comment:
  Good that you're documenting that tailwind.css is built separately. Ensure this remains updated if build processes change.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

2. apps/web/app/layout.tsx:2

• Draft comment:
  Review if inline eslint-disable is necessary. Consider configuring module resolution to avoid disabling the lint rule.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The import is for a CSS file that will be built separately, as indicated by the comment. In Next.js projects, it's common to have CSS files that don't exist until build time. The eslint-disable is likely intentional and necessary since the file doesn't exist in source. Configuring module resolution wouldn't help since this is a build-time artifact.
  Maybe there is a way to configure ESLint to understand Next.js build artifacts? The comment could be pointing to a real improvement in the build setup.
  Even if there is a way to configure ESLint differently, this is a common pattern in Next.js projects and the current solution is working. The comment doesn't provide enough concrete guidance to be actionable.
  Delete the comment because the eslint-disable is intentional and necessary for build-time artifacts, and the suggestion to configure module resolution isn't clearly applicable or actionable.

3. apps/web/app/layout.tsx:1

• Draft comment:
  Clarify why tailwind.css is built separately. Consider linking to documentation or adding additional context if needed.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

4. apps/web/app/layout.tsx:2

• Draft comment:
  Consider moving the eslint-disable comment to the ESLint configuration rather than inline, if possible.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

Workflow ID: wflow_gKQXB772PlxKLSrA

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.