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
Here is my current proposal for supporting this feature: Computed expressions would be allowed in the following places if target is ES6: Object literal properties Class methods and accessors (both static and instance), but not property declarations. 'this' references are not allowed in computed properties. No parameter properties Do not allow in interfaces No enum members Below ES6: Computed prope
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
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
Proposal: Conditional Compilation Problem Statement At design time, developers often find that they need to deal with certain scenarios to make their code ubiquitous and runs in every environment and under every runtime condition. At build time however, they want to emit code that is more suited for the runtime environment that they are targetting by not emitting code that is relevant to that envi
Proposal You simply do require('typescript').register() and then all require calls e.g. var foo = require('./foo') would load foo.ts if foo.js/json/etc are not found. This would mean we would compile in-memory and completely skip all type checking and do a fast emit. This would however greatly help increase .ts adaption IMHO. Currently there is a userland maintained : https://github.com/TypeStrong
An extension to #1692 Our ts project uses a grunt-based build system, with bower dependencies for the application and node_modules for build-tools. We will need the ability to exclude node_modules and bower_components from the build by default (unless files are referenced via /// ). This causes an issue: we have end-to-end tests running in protractor, as well as unit tests running in jasmine, and
Weird behaviour with union types and 'strict' object literals #5237 Weird behavior with strict object literals and union types. Anders will think about it and come up with a fix. Seems tractable. Report use before definitely defined errors #5207 Report use before definition errors Mohamed to implement for classes and imports. A PR exists but it needs updating. Defer implementing member access of s
On the docket today Allow type parameter constraints to reference other type parameters #2304 Allow type parameter constraints to reference other type parameters Boolean literal types and return type propagation for generators #2983 Boolean literal types and return type propagation for generators Why are TS get/set definedProperties in a class transpiled as enumerable/writable? #3610 Why are TS ge
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
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
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く