From the user tests:
```js
const x = require('y').z.ka
```
would cause the crash because I forgot to call
getLeftMmostPropertyAccessExpression in one place.
Note that this doesn't fix the alias, it just stops the crash.
* Modify test harness so it can report underlying issue, fix small parent pointer issue
* Fix underlying export asignment check issue and fix lints
* Ensure class/function duplicate declaration errors are reported regarless of which is encountered first
* Ensure flag conflict errors are reported regardless of which declaration is encountered first
* First attempt at aliases for require
* test+initial support for const x=require
* 1st round of baseline improvements
* 2nd round of baseline updates
* support property access after require
* check @type tag on require
* forbid expando missing namespaces on aliases
taken from #39558 as soon as it was created
* accept error baselines that are good, actually
* Scribbling on d.ts emit code
* use getSpecifierForModuleSymbol
* hideous hack for module.exports of aliases
* Fix module.exports.x --> export list emit
* fix isLocalImport predicate
* require only creates aliases in JS
* re-handle json imports
* update fourslash baseline
* Cleanup in the checker
1. Simplify alias resolution.
2. Simplify variable-like checking.
3. Make binding skip require calls with type tags -- they fall back to
the old require-call code and then check from there.
I haven't started on the declaration emit code since I don't know what
is going on there nearly as well.
* Function for getting module name from require call
* First round of cleanup plus a new test
Found one missing feature, not sure it's worth adding.
* more small cleanup
* more cleanup, including lint
* use trackSymbol, not serializeTypeForDeclaration
* Code review comments, plus remove unneeded code
Ad-hoc type reference resolution for `require` isn't needed anymore.
* find all refs works
* remove old ad-hoc code
* make it clear that old behaviour is not that correct
* update api baselines
* remove outdated comment
* PR feedback
1. Fix indentation
2. Add comment for exported JSON emit
3. Add test case for nested-namespace exports.
* add a fail-case test (which passes!)
* Support recursive conditional types
* Accept new API baselines
* Accept new baselines
* Simplify recursive type tracking in type inference
* Accept new baselines
* Add tests
* Accept new baselines
* Revise recursion tracking in type inference
* Revise tests
* Accept new baselines
* Add more tests
* Accept new baselines
The exception thrown by Node.js's fs.statSync function contains a stack
trace that can be expensive to compute. Since this exception isn't used
by fileSystemEntryExists, we can safely set Error.stackTraceLimit to 0
without a change in behavior.
---
A significant performance improvement was noticed with this change while
profiling tsserver on packages within a proprietary monorepo.
Specifically, my team saw high self time percentages for Node.js's
uvException and handleErrorFromBinding internal functions. These
functions are executed within fs.statSync when it fails to find the
given path.
https://user-images.githubusercontent.com/906558/90183227-220cb800-dd81-11ea-8d61-f41f89481f46.png
fs.statSync: https://github.com/nodejs/node/blob/v14.4.0/lib/fs.js#L1030-L1037
handleErrorFromBinding: https://github.com/nodejs/node/blob/v14.4.0/lib/internal/fs/utils.js#L254-L269
uvException: https://github.com/nodejs/node/blob/v14.4.0/lib/internal/errors.js#L390-L443
## Measurements
After adding Error.stackTraceLimit = 0, we saw:
- For a large configured project with 12,565 files, tsserver reached the
projectLoadingFinish event 48.78% faster. (~46.786s vs ~31.447s)
- For a medium project with 7,064 files, tsserver was 25.75% faster.
(~20.897s vs ~16.618s)
- For a small project with 796 files, tsserver was only a negligible
3.00% faster. (~3.545s vs ~3.442)
Measurements were taken on macOS 10.15.6, Node.js 14.4.0, and a recent
master commit of TypeScript (610fa28d). The average of 3 runs before and
after this change were taken.
I would normally include .cpuprofile and isolate-*-*-*.log files, but
can't post them publicly in this case. If there's any other summaries
the TypeScript team would be curious about I can report them.
## fs.statSync Misses
Within our monorepo, the fs.statSync misses were mostly searches for
alternative file extensions of module imports.
- For node_modules imports, a lot of .ts/.tsx lookups failed until the
.d.ts file was found.
- Within projects with a lot of JSX files, .ts files were looked for
before finding the .tsx version.
- In the medium scale project mentioned above, a total of 38,515
non-existent files were queried during createProgram.
* Bind alias ThisProperty assignment declarations
This is a quick prototype that does the wrong thing at the wrong time
with the wrong technique.
* Preliminary checker handling for aliases
Duplicative and untested, but I think I updated all the places that need
updating.
* new is error; old one should not have been removed
* I don't even know what's happening with this test
* cleanup and testing in the checker
* binder: use lookupSymbolForNameWorker instead of mutable
This should have about the same behaviour and is much easier to
understand.
Also refactor common code a bit.
* Shorter name of lookupSymbolForName
Once upon a time there was a parent/worker function, but now it's just a
single function again. No need for the -Worker suffix.
* remove oodate comment
* fix switch-case-break lint
* Refactor and move functions
* Rename and improve type of getContextualTypeForAssignmentDeclaration
* Preserve the variable name when exporting an arrow or anonymous function
This allows the browser or node to properly name the (arrow) function
* Updated tests to reflect previous change
* Remove duplicated comment
* Transforms variable.initializer using moduleExpressionElementVisitor
* PR feedback: rbuckton
- Use isArrowFunction and isFunctionExpression
* PR feedback: rbuckton
- Consider ClassExpresion, they can also be named based on the
variable.
* Use isUncalledFunctionReference for aliases too
Fixes bogus deprecated notices on imports of functions with deprecated
overloads, but with some non-deprecated overloads.
Fixesmicrosoft/vscode#104238
* Just check all declarations, don't call isUncalledFunction