* Refactoring so CacheWithRedirects has Key and Value type parameters
* ModuleResolutionCache or TypeRefDirectiveCache will look in directory before solving, so ResolutionCache doesnt need this check
* Test showing module resolution is not shared because resolution cache doesnt update own options
* Enable traceResolution on some of the project reference tests
* Simplify CacheWithRedirects and ensure the options are set in all common scenarios so cache can be shared between redirects
* Make failedlookup etc optional in ResolvedModule/TypeRefefWithFailedLookupLocations
Also make accidental public failed lookup internal
* Add new API for module and type ref resolution
* Store auto type reference resolutions
* Modify test to show how using program partially doesnt report resolution diagnostics
* Ensure that resolution diagnostics are reported in filePreocessingDiagnostics so they can be reused when program is reused
* Some cleanup
* Remove the newly added ReoslutionInfo in favor of new APIs
* update
* Refactoring so CacheWithRedirects has Key and Value type parameters
* ModuleResolutionCache or TypeRefDirectiveCache will look in directory before solving, so ResolutionCache doesnt need this check
* Test showing module resolution is not shared because resolution cache doesnt update own options
* Enable traceResolution on some of the project reference tests
* Simplify CacheWithRedirects and ensure the options are set in all common scenarios so cache can be shared between redirects
* Add tests where typeRef resolution is not in the cache
* Ensure that type ref reuse is actually handled since type ref resolution only sends containingSourceFileMode and not containingSourceFile
This adds a "small" d.ts bundler script. This script is very basic,
using Node printing to produce its output. Generally speaking, this is
inadvisable as it completely disregards name shadowing, globals, etc.
However, in our case, we don't care about the globals, and we can opt to
restructure our codebase in order to avoid conflict, which we largely
had to do anyway when we were namespaces and everything was in scope.
If these are regular comments, then they won't appear in our d.ts files.
But, now we are relying on an external d.ts bundler to produce our final
merged, so they need to be present in the "input" d.ts files, meaning
they have to be JSDoc comments.
These comments only work today because all of our builds load their TS
files from scratch, so they see the actual source files and their
non-JSDoc comments.
The comments also need to be attached to a declaration, not floating,
otherwise they won't be used by api-extractor, so move them if needed.
This step converts as many explicit accesses as possible in favor of direct imports from the modules in which things were declared. This restores the code (as much as possible) back to how it looked originally before the explicitify step, e.g. instead of "ts.Node" and "ts.Symbol", we have just "Node" and "Symbol".
This step converts each file into an exported module by hoisting the namespace bodies into the global scope and transferring internal markers down onto declarations as needed.
The namespaces are reconstructed as "barrel"-style modules, which are identical to the old namespace objects in structure. These reconstructed namespaces are then imported in the newly module-ified files, making existing expressions like "ts." valid.
* Test showing wrong resolution is returned because of incorrect mode calculation
Test for #48229
* Pass in information for the module name resolution when resolutions from file are partially used
Fixes#48229
* Make the resolution info complete
* Add test where clearing affected files watcher that also is shared by real path causes Debug failure
* Ensure that file watcher is closed only once for affected file locations that share watcher because of different names but same real path
* Lift up package json map
* Add test where module resolution cache is not local and hence doesnt report errors in watch mode
* Ensure module resolution cache is passed through in watch mode
* Remove unnecessary setting of impliedFormat which should anyways be done as part of create source file
* Add test for packge.json changing and modifying implied format
* Distinguish between package.json watch and affecting file location watch
* Pass in failed lookup and affected file locations for source file's implied format
Also stop creating options if we already have them
* Add diagnostic for explaining file's implied format if based on package.json
* Watch implied format dependencies for modules and schedule update on change
* For program if implied node format doesnt match create new source file. Handle implied node format in document registry
Fixes#50086
* Modify tests to show package.json being watched irrespective of folder its in
* Check file path if it can be watched before watching package.json file
* Because we are watching package.json files and failed lookups its safe to invalidate package json entries instead of clearing them out everytime program is created
* Remove todos
* Fix the incorrect merge
* Pickup PackageJsonInfo renames from #50088
* Rename
* Add moduleDetection compiler flag to allow for changing how modules are parsed
The default setting is 'auto', where JSX containing files under react-jsx and react-jsxdev are
always parsed as modules, and esm-format files under module: node12+ are always parsed as modules,
in addition to the 'legacy' detection mode's conditions for other files. (Declaration files are exempt from
these new conditions)
The 'legacy' mode preserves TS's behavior prior to the introduction of this flag - a file is
parsed as a module if it contains an import, export, or import.meta expression.
In addition, there is a 'force' mode that forces all non-declaration files to be parsed as modules.
(Declaration files are still only modules if they contain a top-level import or export.)
This technically breaks the parser API, but it's kinda-sorta backwards compatible so long
as you don't need the functionality associated with more recent compiler flags.
* Fix post-merge lint
* Rename function
* Update default value documentation
* PR feedback
* Fix lint and typo
* Triple-slash reference type directives can override the import mode used for their resolution
They now use the file's default mode by default, rather than always using commonjs. The new arguments to the
reference directive look like:
```ts
///<reference types="pkg" resolution-mode="require" />
```
or
```ts
///<reference types="pkg" resolution-mode="import" />
```
* Omit redundant import modes in emitter
* Add test for #47806
* Add server test for triple-slash reference mode overrides
* Move FileReference mode into helper
* Update tests/cases/conformance/node/nodeModulesTripleSlashReferenceModeOverride3.ts
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
Co-authored-by: Nathan Shively-Sanders <293473+sandersn@users.noreply.github.com>
* Clean up createMap
* Delete dead createMapFromTemplate
* Clean up assertDefined
* Delete dead assertEachDefined
* Delete dead createUnderscoreEscapedMap
* Delete dead hasEntries
* Delete dead ReadonlyNodeSet, NodeSet, ReadonlyNodeMap, NodeMap
* Use updated SyntaxKind names
* Update API baselines
* Initial support for module: node12
* Add allowJs and declaration emit enabled tests
* Fix typos
* cts, mts, cjs, mjs, etc extension support
* Fix watch of files whose intepretation changes due to a package.json update
* Minor PR feedback
* Adjust error message
* Initial import/export/self-name support
* Accept new error codes
* TypesVersions support in export/import map conditions
* Fix import suggestion and autoimport default extensions under new resolution modes
* Add tests for import maps non-relative name lookup feature
* Fix isDeclarationFileName for .d.mts and .d.cts
* Preserve new extensions when generating module specifiers
* Fix spurious implict any suggestion caused by file ordering bug and optimize import name format detection by relying on parents being set
* Fix a bunch of incremental bugs that dont repro under fourslash for some reason
* Accept updated baseline
* Always include extensions on completions for cjs/mjs style imports
* String completion relative import suggestions respect the mode of the import when choosing if they provide extensions
* Style feedback
* Change diagnostic case
* Make the module resolution cache apis for updating compiler options or clearing it
* Cache package.json lookup results from module resolution
* Use per directory cache for type reference directive resolution as well
* Update Baselines and/or Applied Lint Fixes
* Change trace according to feedback
* Update Baselines and/or Applied Lint Fixes
Co-authored-by: TypeScript Bot <typescriptbot@microsoft.com>
* Update and add test when typings dont change because of import name
* Update project scheduling only when typings are set
* Schedule update graph only if typings change
Fixes#39326
