You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’ve seen some GitHub repositories where people include config files in the root folder. I’m not sure if they fully understand why they’re doing that. I asked an AI about it, and it said that it’s useful for IDEs or for running global commands like tsc or eslint from the root directory. Some Repos even have tailwind.config.js in root folder.
So, I actually have two questions:
1. Why do we still need config files in the root?
Even when every package has its own configuration and shared base configs, why do we still need additional config files in the root of the repository?
It feels redundant unless there’s a specific purpose I’m missing.
It would be great to see some examples of when and why this is useful.
Also i was interested how environment variables handled when we have multiple apps because theirs envs differ and in build script defintion i should specify env and passThroughEnv, i thought i could move them into specific apps and packages extended turbo configuration, but i am not sure if this is right way and also if linter can understand it.
I also would like to ask which env field in turbo.json eslint watches? build one, dev one, its a bit confusing. and if i defined envs in env field and in shell there is no envs exported however they are with .env does it mean we hash whole .env file or it hashes only env variables defined from env field to calculate cache hash to invalidate it or not.
2. How does tsserver and the TypeScript compiler understand the dependency graph?
For example, in a Next.js app, when I run tsc, there might be internal packages installed that aren’t plain JS files — they’re transpiled and bundled by Next.js.
So does that mean the build uses Next.js’s own tsconfig? How exactly does the Next.js build process and bundler handle this?
Also, what happens if that internal package depends on other packages, each with their own tsconfig files? They might be different but still compatible. Since there’s usually one tsserver running per workspace, how does it handle multiple apps and packages with separate tsconfigs within the same monorepo?
Also, i want to know how turbo revalidate, for example, build cache when internal package changed and other packages depend on it that are part of app. I know package.json is part of input of hash calculation, however i dont know leaf packages in the dependency graph that are transpiled and bundled by app build process itself if they are inputs of the app build hash function?
Basically, I want to understand how dependency resolution works — both from the Next.js build process side and the IDE’s tsserver side.
I know tsserver is a big topic, and it’s not easy to learn everything in depth due to time constraints, but this is important to me — especially when working in Turborepo, since I want to understand the logic behind how these things actually fit together.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
I’ve seen some GitHub repositories where people include config files in the root folder. I’m not sure if they fully understand why they’re doing that. I asked an AI about it, and it said that it’s useful for IDEs or for running global commands like
tscoreslintfrom the root directory. Some Repos even havetailwind.config.jsin root folder.So, I actually have two questions:
1. Why do we still need config files in the root?
Even when every package has its own configuration and shared base configs, why do we still need additional config files in the root of the repository?
It feels redundant unless there’s a specific purpose I’m missing.
It would be great to see some examples of when and why this is useful.
Also i was interested how environment variables handled when we have multiple apps because theirs envs differ and in build script defintion i should specify env and passThroughEnv, i thought i could move them into specific apps and packages extended turbo configuration, but i am not sure if this is right way and also if linter can understand it.
I also would like to ask which env field in turbo.json eslint watches? build one, dev one, its a bit confusing. and if i defined envs in env field and in shell there is no envs exported however they are with .env does it mean we hash whole .env file or it hashes only env variables defined from env field to calculate cache hash to invalidate it or not.
2. How does
tsserverand the TypeScript compiler understand the dependency graph?For example, in a Next.js app, when I run
tsc, there might be internal packages installed that aren’t plain JS files — they’re transpiled and bundled by Next.js.So does that mean the build uses Next.js’s own tsconfig? How exactly does the Next.js build process and bundler handle this?
Also, what happens if that internal package depends on other packages, each with their own tsconfig files? They might be different but still compatible. Since there’s usually one
tsserverrunning per workspace, how does it handle multiple apps and packages with separate tsconfigs within the same monorepo?Also, i want to know how turbo revalidate, for example, build cache when internal package changed and other packages depend on it that are part of app. I know package.json is part of input of hash calculation, however i dont know leaf packages in the dependency graph that are transpiled and bundled by app build process itself if they are inputs of the app build hash function?
Basically, I want to understand how dependency resolution works — both from the Next.js build process side and the IDE’s tsserver side.
I know
tsserveris a big topic, and it’s not easy to learn everything in depth due to time constraints, but this is important to me — especially when working in Turborepo, since I want to understand the logic behind how these things actually fit together.Beta Was this translation helpful? Give feedback.
All reactions