It would be nice to be able to extract a more exact field type when using the “number of records” validation rule for modular content fields (using graphql codegen).
Example of an optional “Link” block:
This means the CDA can return data like:
Codegen will generate a type:
When accessing the modular content field with link[0] we still get LinkRecord type while the type can be undefined as well. We can of course mitigate this issue by using noUncheckedIndexedAccess tsconfig compiler rule to enforce checking for undefined values (this has other implications, more on that later).
The compiler rule does not however help our developers to differentiate between optional modular content fields just by looking at the generated types / schema. We can only see the validation rules from within Dato.
It would make sense if codegen could generate a type like this when a modular content field can be left without any blocks i.e. an optional field:
Related note about using “noUncheckedIndexedAccess”
Using noUncheckedIndexedAccess is tricky because it can also surface issues with third party packages that come with the .ts source. Skipping type checking can’t be avoided for code in “node_modules” at this point .
For example, the dato rest client includes the source code in the NPM package which fails type checking with “noUncheckedIndexedAccess” enabled. This prevents us from publishing code changes with this compiler setting as it doesn’t pass through our CI.
Maybe consider removing the unnecessary(?) .ts source from your NPM packages?
opened 07:48PM - 21 May 21 UTC
closed 07:47PM - 27 May 21 UTC
Suggestion
Declined
## 🔍 Search Terms
node_modules
exclude
alwaysStrict
## ✅ Viability Check… list
My suggestion meets these guidelines:
* [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [X] This wouldn't change the runtime behavior of existing JavaScript code
* [X] This could be implemented without emitting different JS based on the types of the expressions
* [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [X] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
## ⭐ Suggestion
Allow compiler options that enable strict checking to only apply to project files only, and not imported modules.
[Edit 3] It is ideal if this can be expanded to suppress linter checks on node_modules, as well a strict checks.
[Edit 2]
A implementation proposal:
Provide a new configuration option `--noStrictCheckOnNodeModule`. This flag will prevent errors emitting on files referenced via `**/node_modules/**`. This may be further restricted to if the real-path of fire either within `**/node_modules/**` or outside the Project Root. Project Root may defined as the location of package.json. No additional configuration is possible. All strict mode checks are suppressed for these files.
## 📃 Motivating Example
A project imports a npm package, that contains .ts files.
Project compiles, and types are coherent.
Attempting to enable `noImplictReturns`, finds errors in the `node_modules/` in an included project, and fails to compile.
The typing in the third-party library is correct: `public static getTrigger(): undefined | "load" => { if (check()) return "load"; } `
Though, the method has an implicit return.
I see no reason why the project should fail to compile, especially in this case, where the difference between `return undefined` and `/* implicit return undefined */ ` is effectively a style issue with no impact on typing or behaviour. Doubly so, in that the errors are found in a third-party library, in code that is otherwise unused.
The above is a trivial example, but highlights the issue.
## 💻 Use Cases
The primary use case, is to include strict type checking within a project.
The project in question is a library, and not an application.
The project was originally written with all strict checks enabled.
Over time, as more libraries publish only raw `ts` files (1), our project had to disable strict checks one by one, in order to compile.
At this point in time, the project is unable to enable *any* strict type checking, or linter checks at all, lest `tsc` report errors within the `node_modules` directory.
The main shortcomings, is that `tsc` can no longer be used to enforce strict adherence to guidelines, due to changes in third-party libraries. This has immediate impact on code quality. In particular, being unable to enable `strictNullChecks` on our library due to third-party library code, has negatively impacted code quality over time.
Currently, no workarounds have been found.
The best effort currently, is to check out a PR; enable all strict typings; sift through pages of reported errors, and attempt to find those not in `node_modules`. And then approve or deny based on whether any "real errors" were found. This leaves much room for error, and not all developers or reviewers may be diligent in finding a "real error". Whereas, it would be ideal for these sorts of errors to be reported at develop time, or on the build server.
----
(1) Against guidelines, an increasing number of libraries only publishing raw ts files, without providing any `.js` files. In these libraries, `package.json` refer to `.ts` files directly.
```json
{
"module": "./src/main.ts",
"types": "./src/main.ts",
}
```
(2) This appears to be a common request on stack overflow, and elsewhere:
- [Typescript strict null checks with limited scope](https://stackoverflow.com/questions/40164034/typescript-strictnullchecks-with-limited-scope)
- [TSConfig JSON doesn't exclude folder node_modules](https://stackoverflow.com/questions/59324570/tsconfig-json-doesnt-exclude-folder-node-modules-properly)
- [Typescript throws errors in node_modules with strict complier options](https://stackoverflow.com/questions/44305143/typescript-throws-errors-in-node-modules-with-strict-compiler-options)
- [Typescript Configuration to disable strict mode check for node_modules content](https://stackoverflow.com/questions/58023872/typescript-configuration-to-disable-strict-mode-check-for-node-modules-content)
---
Change History:
1. Added stack overflow links of other searching for the same problem.
2. Updated description with clarification of scope.
3. Added desire to include "linter checks" as well as "strict checks". I was unaware that `noImplicitReturn` was in a different category than `Strict Checks`.
