Component commits:
d8f251b90a Avoid repeating codefix work when resolving auto-import specifiers for completions
Co-authored-by: Andrew Branch <andrew@wheream.io>
* fix(49223): handle ExpressionWithTypeArguments nodes in isExpressionNode
* Update src/compiler/utilities.ts
* Just use `!isHeritageClause(node.parent)`.
Co-authored-by: Daniel Rosenwasser <DanielRosenwasser@users.noreply.github.com>
Co-authored-by: Oleksandr T <oleksandr.tarasiuk@outlook.com>
Component commits:
b846905041 Add failing test
66d51e5114 Fix the implicit glob key so that recursive keys are not differing just by directory seperator Fixes#49078
f93951f4b8 Reset the reload level once program is loaded
Co-authored-by: Sheetal Nandi <shkamat@microsoft.com>
Component commits:
5d13ab280d moduleDetection: auto makes cjs files parse as modules, module: node sets moduleDetection: force
Co-authored-by: Wesley Wigham <t-weswig@microsoft.com>
Component commits:
79957c179e Fix index fallback of CJS package from ESM-mode import when `main` is present but does not resolve
Co-authored-by: Andrew Branch <andrew@wheream.io>
Component commits:
94cf1272e5 Fix `isVariableDeclarationInitializedToBareOrAccessedRequire` returning true on binding elements
fae1bbedc1 Undo auto format change
Co-authored-by: Andrew Branch <andrew@wheream.io>
Component commits:
4c6e802772 Remove bigint from Object.freeze in es5.d.ts
`BigInt` isn't resolved whenever `lib < es2020`, but it's not an error
when `target < es2020`. I have a few ideas for improving this situation
but for the RC I'm going to remove `bigint` from Object.freeze's
signature.
6d5bf6a5ee Update other baselines
e1958f7a23 No errors for missing apparent type of bigint,symbol for any target
86fc8dbd0b Update test text
Co-authored-by: Nathan Shively-Sanders <nathansa@microsoft.com>
* Allow export map entries to remap back to input files for a program
* Fix file casing issues on windows
* Implement abiguity error, doesnt quite work
* Refine selection logic in error case to use getCommonSourceDirectory, add more tests
* No error on toplevel return in JS
Turns out it's only an error in modules.
It's possible to keep this error on the list of "OK for JS" errors and
make the checker code stop issuing it for JS scripts only. However, I
don't think the error is valuable enough to do that.
Fixes#48224
* Restore 'return' statement.
* Update Baselines and/or Applied Lint Fixes
* Re-add missing baselines
* No error in toplevel script files
Only issue "no top-level return" error for modules, not scripts,
regardless of whether it's TS or JS.
* Keep Disallowing return in ambient locations
* Allow toplevel return only in non-ESM JS files
* Add test of toplevel return in JS script
* Revert "Add test of toplevel return in JS script"
This reverts commit 2a6dec475a35ec104915000984ffb79452cb7350.
* Revert "Allow toplevel return only in non-ESM JS files"
This reverts commit 6291ae3ba2df305d287f02223d634e21808fd15a.
* Revert "Keep Disallowing return in ambient locations"
This reverts commit 714ea8e524ff1129d94679df78f7790534222980.
* Revert "No error in toplevel script files"
This reverts commit 2056e13d5294a4d923b3f7c8e43dbc72f595afc6.
* restore orphaned baseline
Co-authored-by: Daniel Rosenwasser <DanielRosenwasser@users.noreply.github.com>
Co-authored-by: TypeScript Bot <typescriptbot@microsoft.com>
* Skip ambient modules in globalThis
Previously, globalThis mistakenly included ambient modules, even though
these are not values:
```ts
declare module "ambientModule" {
export type typ = 1
export var val: typ
}
type Oops = (typeof globalThis)[\"ambientModule\"]
```
This PR adds ambient modules to the kinds of things that are skipped
when constructing `globalThis`' properties, along with block-scoped
variables.
* Skip only modules with every declaration ambient
The modules are required to have at least one declaration so that our
treatment of `globalThis` stays the same, and
`globalThis.globalThis.globalThis` remains legal.
