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
Since we updated from TS server 1.6 to 1.7 we notice sporadic crashes in the TS server for our VS Code code base that has around 1100 typescript files in one project. When I compare 1.6 with 1.7 I notice that you changed the strategy for watching for file changes from fs.watchFile to fs.watch. The latter is recommended because it leverages native file watching while the former is polling for chang
After reading and commenting in #4665 and #4673, I felt like I'd gotten a pretty good idea for what we wanted to accomplish regarding package typings - and I believe our main concern was the pulling needs between properly representing the isolation that modules have from one another and the desire to enable consumer to reuse typings between "flat" or browser projects and commonjs based projects. I
Acquiring Typings as Packages (#5537, typings/discussions#3) This is fairly important given that getting typings is a big pain point for customers. Blake has an implementation of a typings registry. What is the workflow between Typings' registry and npm? Considering distributing typings as npm packages. SystemJS and AMD introduce certain complications. How does this system figure out the conflicti
String literal types (#5185, #5156, #1003) These types describe values that can be of certain literal values They are introduced on to string literals via contextual typing Very similar to enums in their semantics Compared using string equality (case-sensitive, escaping/etc does not matter) What's the difference compared to string enums? Less complex We don't need symbolic names for strings like w
In an effort to better support down-level transformations for complex emit like generators and Async Functions, and to be able to add new down-level transformations for the evolving ECMA-262 specification, we propose to replace the current emitter logic for the TypeScript compiler with an implementation that relies on transformations of the source tree. Our current emitter is not built to handle t
Pre-reading JSX in TypeScript refresher: #3203 Original issue: #4861 Announcement: https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html Docs: https://facebook.github.io/react/docs/reusable-components.html#stateless-functions Intro: https://medium.com/@joshblack/stateless-components-in-react-0-14-f9798f8b992d#.d6c0m2mhd Source: https://github.com/facebook/react/blob/0ef5112e892b2350756
12月7日(米国時間)、MicrosoftはWebブラウザー「Microsoft Edge」のJavaScriptエンジンを、「ChakraCore」としてオープンソース化すると発表した。今回はMicrosoftとオープンソースの関係について考えてみる。 2000年代のMicrosoftはオープンソース陣営(特にLinux)をライバル視していた。当時のCEO、Ballmerは2001年に「GNU GPLはガンのようなものだ」といった主旨の発言をして物議を醸していた。あれから14年。Nadella体制では「Microsoft loves Linux」とオープンソースへの取り組みを強くアピールしている。 さて、Microsoftがオープンソースに関与し始めたのは、いつの頃からだろうか。調べてみると2010年7月の「OpenStack」プロジェクトの支援から始まり、2013年1月には「Visua
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く