⌘K
ADALIGO **sw** 👉 I’d recommend: * Have a **root `eslint.config.js`** * Set: ```javascript parserOptions: { project: true, tsconfigRootDir: process.cwd(), } ``` 👉 And inside each package: ```javascript parserOptions: { project: "./tsconfig.json", tsconfigRootDir: __dirname, } ``` That fixes most `tsconfigRootDir` issues 👍 Also quick note: if you're using the new flat config, it doesn’t use `extends` anymore — that’s why it looks inconsistent. For the `tsconfigRootDir` issue, do this: ```javascript import js from "@eslint/js"; import tseslint from "typescript-eslint"; export default [ js.configs.recommended, ...tseslint.configs.recommended, { files: ["**/*.ts", "**/*.tsx"], languageOptions: { parserOptions: { project: true, tsconfigRootDir: process.cwd(), }, }, }, ]; ``` 👉 And if you have configs inside each package: ```javascript tsconfigRootDir: import.meta.dirname ``` That’s it — flat config = no `extends`, and `tsconfigRootDir` must be explicit 👍 Try this repo to on Github to see more about flat config
sw Thanks for pointing me in the right direction. I followed your advice and it worked. I did make some adjustments though. According to https://typescript-eslint.io/blog/project-service/#configuration . ```diff -project: true, +projectService: true, ``` But even after that, im getting the following error ```typescript Parsing error: /project_path/apps/site/eslint.config.js was not found by the project service. Consider either including it in the tsconfig.json or including it in allowDefaultProject. eslint ``` So I also added this: ```diff -projectService: true, +projectService: { allowDefaultProject: ['*.js'] }, ``` originally had `allowDefaultProject` set to `eslint.config.js`. Not sure which one makes more sense, thoughts?
Codex 5427 Yeah I know
ADALIGO 😄 Haha... imagine creating a brand new account just to write: "Yeah I know." But anyway... let me tell you something maybe you *don't* know yet: Even if someone knows a lot, nobody knows everything. Real builders stay humble. Real engineers keep learning. 🚀 Knowledge is not about acting bigger than others. It's about helping, encouraging, building, and evolving together. So whether you're senior, junior, beginner, or expert: keep learning 📚 keep building ⚡ keep improving 🧠 Because technology moves fast... and the moment someone thinks they know everything, they already stopped growing. Still building. Still learning. Still evolving. 🌍🔥 ***Real knowledge is not saying:*** ***"Yeah I know."*** ***Real knowledge is understanding*** https://community.vercel.com/t/introductions-2026/39946?u=nfdcopilot-5305 SAY HI TO VERCEL COMMUNITY
Community Backoffice Hey! To help debug your v0 project, could you share your **v0 chat link**? It looks like `https://v0.app/chat/...` — you can copy it from your browser's address bar while in the chat. You'll also need to unlist the chat so our team can view it — here's how: https://v0.app/docs/sharing This helps the team reproduce what you're seeing much faster. Thanks!
maciejcaputa https://community.vercel.com/t/preview-design-mode-don-t-work-for-imported-turborepo-monorepo-projects-in-v0/32954 I’ve got the same problem
Anthony Shew This is likely the background daemon, though it’s hard to tell with the screenshot given. Is it idling or does it appear to be running and consuming resources?
Gixoqqpt 6065 Yes, I did not configure the daemon property separately in the project. I saw in the document that the default is to allow background running. Now the strange problem is that after I finished the project and removed the file directory and it is not on the computer’s disk, I can still see the turbo running and consuming resources in the process, and the CPU usage is also relatively high.
