GitHub - microsoft/deoptexplorer-vscode: A VS Code extension to visualize deoptimizations in your JavaScript and TypeScript code running in V8 (i.e., NodeJS, Edge, Chrome, etc.).You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
package.json `exports` resolution uses fallback conditions, unlike Node · Issue #50762 · microsoft/TypeScript
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account
`--moduleResolution bundler` (formerly known as `hybrid`) by andrewbranch · Pull Request #51669 · microsoft/TypeScript
This PR introduces a new moduleResolution setting value called hybrid bundler (see #51714), designed primarily for bundlers and runtimes that include a range of Node-like resolution features and ESM syntax, but do not enforce the strict resolution rules that accompany ES modules in Node or in the browser. Special consideration has also been given for bundlers and runtimes that understand TypeScrip
A Proposal For Module Resolution · Issue #50152 · microsoft/TypeScript
Background When a user writes a module specifier (the string literal after from in an import declaration) in a TypeScript file, how should the compiler resolve that string to a file on disk to be included in type checking? Because TypeScript never rewrites module specifiers in its JavaScript emit, the only possible answer is that it should mirror whatever resolution behavior the code’s intended ru
Implement the Stage 3 Decorators Proposal by rbuckton · Pull Request #50820 · microsoft/TypeScript
This implements support for the Stage 3 Decorators proposal targeting ESNext through ES5 (except where it depends on functionality not available in a specific target, such as WeakMaps for down-level private names). The following items are not currently supported: --emitDecoratorMetadata, as metadata is currently under discussion in https://github.com/tc39/proposal-decorator-metadata and has not ye
GitHub - microsoft/vscode-markdown-languageservice: The language service that powers VS Code's Markdown support, extracted so that it can be reused by other editors and tools
This library targets CommonMark. Support for other Markdown dialects and extensions is not within the scope of this project. Currently supported language features: Document links (clickable spans in the editor) Supported links include: Links to headers within the current file: [text](#header) Absolute and relative links to files: [text](path/to/file.md) Reference links: [text][link-name] Document
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Release v1.33.0 · microsoft/playwright
Suggestion: Const contexts for generic type inference · Issue #30680 · microsoft/TypeScript
Release v1.29.0 · microsoft/playwright
Delete type search by andrewbranch · Pull Request #2625 · microsoft/TypeScript-Website
Release v1.28 · microsoft/playwright
TypeScript 5.0 Iteration Plan · Issue #51362 · microsoft/TypeScript
Support for auto-accessor fields from the Stage 3 Decorators proposal by rbuckton · Pull Request #49705 · microsoft/TypeScript
Release v1.26.0 · microsoft/playwright
Release v1.24.0 · microsoft/playwright
Release v1.23.0 · microsoft/playwright
TypeScript 4.7 source map file extension mismatch · Issue #49335 · microsoft/TypeScript
allow voluntary .ts suffix for import paths · Issue #37582 · microsoft/TypeScript
TypeScript Design Goals
Release v1.22.0 · microsoft/playwright
