Update NoResolution.md

there was a typo

Author: phapdinh

docs/problems/NoResolution.md

@@ -15,7 +15,7 @@ This problem indicates that TypeScript can’t find any file with a supported fi
 
 ### False positive: unsupported file extension
 
-TypeScript doesn’t record non-JS/TS files as resolution results, and its API can’t be used to distinguish between a result with an unuspported file extension and a non-existent file. If a package.json subpath exposes a non-JS asset like a `.css` file, designed to be processed by a bundler or runtime extension, this will show up as a failed resolution, when it might be more accurately described as an [untyped resolution](./UntypedResolution.md) of an unknown file type.
+TypeScript doesn’t record non-JS/TS files as resolution results, and its API can’t be used to distinguish between a result with an unsupported file extension and a non-existent file. If a package.json subpath exposes a non-JS asset like a `.css` file, designed to be processed by a bundler or runtime extension, this will show up as a failed resolution, when it might be more accurately described as an [untyped resolution](./UntypedResolution.md) of an unknown file type.
 
 If the asset is intended to be imported as a side-effect import (`import "pkg/styles.css"`), this problem can safely be ignored.
 
@@ -36,4 +36,4 @@ When this problem occurs for the `node10` resolution option but not any others,
 
 In this example, an import of `"pkg/subpath"` can be used in Node 12+ and modern bundlers, but would fail to resolve in Node 10. Accordingly, TypeScript’s `--moduleResolution node10` (also confusingly known as `node`, because history) does not resolve `"exports"` either.
 
-While few libraries care about supporting a long-past EOL version of Node, maintainers of very popular libraries should be aware that many TypeScript users are still using `--moduleResolution node`. If they aren’t literally using Node 10, they really should move away from it, but sometimes migrating can be difficult because it introduces new errors caused by _incorrect dependency typings_—the problem this tool was made to diagnose. Popular libraries often choose to adopt a strategy that allows `--moduleResolution node10` to work even without `"exports"` support. https://github.com/andrewbranch/example-subpath-exports-ts-compat demonstrates several such strategies.
+While few libraries care about supporting a long-past EOL version of Node, maintainers of very popular libraries should be aware that many TypeScript users are still using `--moduleResolution node`. If they aren’t literally using Node 10, they really should move away from it, but sometimes migrating can be difficult because it introduces new errors caused by _incorrect dependency typings_—the problem this tool was made to diagnose. Popular libraries often choose to adopt a strategy that allows `--moduleResolution node10` to work even without `"exports"` support. https://github.com/andrewbranch/example-subpath-exports-ts-compat demonstrates several such strategies.