From d77366bb4e7a1794e16479065b4e633a570d0a23 Mon Sep 17 00:00:00 2001 From: Anthony Shew Date: Tue, 22 Oct 2024 15:42:08 -0600 Subject: [PATCH 1/2] Add list item in docs about errors in internal TypeScript dependencies. --- docs/repo-docs/core-concepts/internal-packages.mdx | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/repo-docs/core-concepts/internal-packages.mdx b/docs/repo-docs/core-concepts/internal-packages.mdx index 95835e6a2edbd..d6c444c9406c5 100644 --- a/docs/repo-docs/core-concepts/internal-packages.mdx +++ b/docs/repo-docs/core-concepts/internal-packages.mdx @@ -97,6 +97,7 @@ There are a few important things to notice in this `package.json`: - **Only applicable when consumers do transpiling**: This strategy can only be used when the package is going to be used in tooling that uses a bundler or natively understands TypeScript. The consumer's bundler is responsible for transpiling the TypeScript packages to JavaScript. If your builds or other usages of the package are not able to consume TypeScript, you will need to move to the [Compiled Packages](#compiled-packages) strategy. - **No TypeScript `paths`**: A library that is being transpiled by its consumer cannot use the `compilerOptions.paths` configuration because TypeScript assumes that source code is being transpiled in the package where it is written. If you're using TypeScript 5.4 or later, we recommend [using Node.js subpath imports](https://devblogs.microsoft.com/typescript/announcing-typescript-5-4/#auto-import-support-for-subpath-imports). To learn how, visit [our TypeScript page](/repo/docs/guides/tools/typescript#use-nodejs-subpath-imports-instead-of-typescript-compiler-paths). - **Turborepo cannot cache a build for a Just-in-Time Package**: Because the package doesn't have its own `build` step, it can't be cached by Turborepo. This tradeoff may make sense for you if you want to keep configuration to a minimum and are okay with the build times for your applications. +- **Errors in internal dependencies will be reported**: When directly exporting TypeScript, type-checking in a dependent package will fail if code in a dependency has TypeScript errors. You may find this confusing or problematic in some situations. ### Compiled Packages From 2f9073c4c37f1b57dc3ac0b3e523add2753465a1 Mon Sep 17 00:00:00 2001 From: Anthony Shew Date: Tue, 22 Oct 2024 16:13:31 -0600 Subject: [PATCH 2/2] Update docs/repo-docs/core-concepts/internal-packages.mdx --- docs/repo-docs/core-concepts/internal-packages.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/repo-docs/core-concepts/internal-packages.mdx b/docs/repo-docs/core-concepts/internal-packages.mdx index d6c444c9406c5..15935784c2bb6 100644 --- a/docs/repo-docs/core-concepts/internal-packages.mdx +++ b/docs/repo-docs/core-concepts/internal-packages.mdx @@ -97,7 +97,7 @@ There are a few important things to notice in this `package.json`: - **Only applicable when consumers do transpiling**: This strategy can only be used when the package is going to be used in tooling that uses a bundler or natively understands TypeScript. The consumer's bundler is responsible for transpiling the TypeScript packages to JavaScript. If your builds or other usages of the package are not able to consume TypeScript, you will need to move to the [Compiled Packages](#compiled-packages) strategy. - **No TypeScript `paths`**: A library that is being transpiled by its consumer cannot use the `compilerOptions.paths` configuration because TypeScript assumes that source code is being transpiled in the package where it is written. If you're using TypeScript 5.4 or later, we recommend [using Node.js subpath imports](https://devblogs.microsoft.com/typescript/announcing-typescript-5-4/#auto-import-support-for-subpath-imports). To learn how, visit [our TypeScript page](/repo/docs/guides/tools/typescript#use-nodejs-subpath-imports-instead-of-typescript-compiler-paths). - **Turborepo cannot cache a build for a Just-in-Time Package**: Because the package doesn't have its own `build` step, it can't be cached by Turborepo. This tradeoff may make sense for you if you want to keep configuration to a minimum and are okay with the build times for your applications. -- **Errors in internal dependencies will be reported**: When directly exporting TypeScript, type-checking in a dependent package will fail if code in a dependency has TypeScript errors. You may find this confusing or problematic in some situations. +- **Errors in internal dependencies will be reported**: When directly exporting TypeScript, type-checking in a dependent package will fail if code in an internal dependency has TypeScript errors. You may find this confusing or problematic in some situations. ### Compiled Packages