* Don’t offer to extract export assignment
* Terminate unterminated literals when extracting them
* Add test with regular expression ending in backslash
* Add test for string literal ending in backslash
* Remove unused parameter default
When handling an array type, the lookup should use the position index
instead of the identifier name.
Also uncomment the tests in the `staticFieldWithInterfaceContext.ts`
test which failed because of this bug.
Fixes#40158.
The commonjs-specific code for resolving access expressions on `require`
assumes a fake commonjs export. For real exports, it needs to call
resolveSymbol since it's outside the normal alias-resolving
infrastructure.
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.
