Official TypeScript definitions? #81
Comments
|
Yes. We are working on it :)
|
|
Awesome! I also vote for the official definitions. BTW, for modules that are written in TypeScript, you can emit definitions from them and don't have to maintain manual |
|
@BalassaMarton @omidkrad thanks for your interest !! here are some links to preliminary work :) automatic dts generation - process document aurelia libs ported to typescript |
|
Hi @cmichaelgraham I read the dts generation doc it's a good start but as mentioned in the document, it only gives stong-typing for the types that can be inferred by the TypeScript compiler. But we're still missing a lot, explicit type definitions, union types, enums, etc. I'm sure Aurelia team has good reasons with going with pure ES6 code, but for me the benefits from typing outweighs the fact that the Babel compiler currently has more ES6 features implemented. I wished the decision was the other way around, i.e. using TS for source code and then transcompiling to ES6. That way you'd get both |
|
We are considering TS as an option for our main source. We can't do it now because TS doesn't support everything we need just yet. They know what we need and are working on it though. That said, it's still a decision that needs to be made carefully. If we switch to TS that may just upset the community and ruin us. I don't know just yet. I would like to investigate further into a dual compilation strategy. My thought is that we could introduce types into the source in a way that they could be processes by Babel via Flow as well as TS at the same time. I don't know if anyone has tried that before, but it might be worth a shot. |
|
thanks for the great input :) independent of the above decision about aurelia source, there is tremendous value in increasing the type specificity in the ported code which will, in turn, increase the specificity of the generated type definitions. i am working hard to try to make sure that typescript is well supported. |
|
I like the dual compilation strategy. I was thinking maybe could use Closure Compiler Type Annotations that could be translated to TS syntax in the conversion process. |
|
One thing is that Flow types use the same syntax as TypeScript and are already supported by Babel. So, I think that might be a better fit for us. I need to investigate a bit more. @cmichaelgraham If you are interested, this would be a related area worth looking into. |
|
wow - its the same syntax? that is very cool. i will put it on the list for sure 👍 |
|
I think it is. It doesn't have interfaces I don't think. If we were careful, we might be able to craft our code base so that it could be compiled both by TS and Babel with Flow....and that would be pretty cool. |
|
We could start to experiment with this on one repo first, like metadata, for example. See how it works, then go one repo at a time from there maybe. |
|
i'm with you 100% |
|
In their announcement they said that they will be compatible with TypeScript definitions ( |
|
@omidkrad for reference, here is a comparison of TypeScript with Facebook Flow Type System microsoft/TypeScript#1265 |
|
I have mixed feelings about Flow, but looks like it has some more type checking and features compared to TypeScript. Stricter type checking means that code that passes Flow type checking should also pass TypeScript type checking but more features means that code that uses Flow-only features will fail if compiled as TypeScript. |
|
OK, I see we're talking about the Babel Flow transformer. So we're not going to use Flow, just the typing syntax which is going to be the same as TypeScript (except for nullable types?). What if the Aurelia build process did the following?
If both compilation steps pass then we have a code that is compatible with the least common denominator of both languages. If anything fails then we get the appropriate error message from the respective compiler. Being able to configure which compiler output to deploy allows the developer to choose how they want to debug the code in the browser. |
|
I think something like that is a possibility. We just haven't had the opportunity to test that out just yet... |
|
Which ES6 features you need in Aurelia framework that are not supported in TS yet? |
|
With 1.5, we have the language features we need. There are a few tooling issues related to cross-repo compiling and builds that I believer are lingering. @cmichaelgraham can comment on that. |
|
Any news on this? |
|
We are planning to experiment with a hybrid compilation strategy on a couple of our small libraries, starting next week, in order to see if we can generate all the d.ts files ourselves. In the mean time, @cmichaelgraham has a repo you can use. |
|
I think Typescript is the way to go. I feel that using Typescript features such as 'implement/interface' will be better for making third party plugings/extensions. Also I think enforcing the SOLID principles with Typescirpt at the Auerlia library level will promote higher QA standards for the community in general. |
|
Please, allow me to add my one cent for TS. I think is is said enough in @cmichaelgraham Aurelia/TS article's comments in the Aurelia blog. It make sense to switch to TS for many reasons. And I am personally not for dual compilation strategy. This is not something that should be this flexible. I'll explain why if you allow me. We all learn from others. We read something there and there, then we discover something on our own. If there will be 2 ways to compile Aurelia, one will become more popular and another one less. All will depends what in particular will be described in tutorials over internet. And if at the end people will use mostly one method, another one will not worth efforts to be supported. At the end of the day, there will be only one method left anyway. And another reason that might sound not significant or not true, but to be 2 different method of compiling would be confusing. If I would be and new to Aurelia and just stared, then I read one article then another and in both of them different methods described I would have a question, which one is better, what are difference, .... I understand that TS is not yet ready for Aurelia just now. But I would definitely look at TS as the ONLY way in the future. Sorry if sound silly. If my post is unapropriate, you can delete it. |
|
I agree with you 100%. It makes sense to only support one. And since any JS On Mon, 8 Jun 2015 at 07:37 Sergey Romanov [email protected] wrote:
|
|
I agree :) Time to gear up a level. |
|
I also agree with you. TypeScript IS JavaScript with good sugar! |
|
I also 100% agree. |
|
@kristianmandrup I'm interested |
|
update: looking at route-recognizer branch as a model for each aurelia repo created PR to fix the generated here is the generated declare module 'aurelia-route-recognizer' {
import core from 'core-js';
export interface RouteHandler {
name: string;
}
export interface ConfigurableRoute {
path: string;
handler: RouteHandler;
}
export interface HandlerEntry {
handler: RouteHandler;
names: string[];
}
export interface RecognizedRoute {
handler: RouteHandler;
params: Object;
isDynamic: boolean;
}
export class RouteRecognizer {
constructor();
add(route: ConfigurableRoute | ConfigurableRoute[]): any;
handlersFor(name: string): HandlerEntry[];
hasRoute(name: string): boolean;
generate(name: string, params: Object): string;
generateQueryString(params: Object): string;
parseQueryString(queryString: string): Object;
recognize(path: string): RecognizedRoute[];
}
class RecognizeResults {
constructor(queryParams: Object);
}
export class StaticSegment {
constructor(string: any);
eachChar(callback: any): any;
regex(): any;
generate(): any;
}
export class DynamicSegment {
constructor(name: any);
eachChar(callback: any): any;
regex(): any;
generate(params: any, consumed: any): any;
}
export class StarSegment {
constructor(name: any);
eachChar(callback: any): any;
regex(): any;
generate(params: any, consumed: any): any;
}
export class EpsilonSegment {
eachChar(): any;
regex(): any;
generate(): any;
}
export class State {
constructor(charSpec: any);
get(charSpec: any): any;
put(charSpec: any): any;
match(ch: any): any;
}
} |
|
@cmichaelgraham I'm wondering, could we remove the core-js import from the type definition file? What happens when you try to use this d.ts to code against? Any issues with or without that part? |
|
once we have a few repos generating types, i can experiment. it seems to me that we would not need it. |
|
I really want to contribute to add TypeScript type definitions. Sorry for my poor english... |
|
your english is fine 👍 once we get the pattern for parameter typing, interface declaration and usage, and basics (like declaring class members), changes to the repos for typescript typing will be the same as regular pull requests for other code changes 👍 |
|
Ok I'm waiting the signal ^^ |
|
@cmichaelgraham Are you thinking about generating documentation into the d.ts as well? I don't see that in your example. I realize that most people have their eyes on the benefits of type constraints. But there is huge value in propagating some meaning into the intellisense along with syntax. It's not hard to pass those comments along to the d.ts. Maybe there just aren't docs in the source code? |
|
@wardbell great call !! :) :) ping @EisenbergEffect shazam !! needs some formatting, but making progress... babel-dts-generator with inline comments: declare module 'aurelia-route-recognizer' {
import core from 'core-js';
export interface RouteHandler {
name: string;
}
export interface ConfigurableRoute {
path: string;
handler: RouteHandler;
}
export interface HandlerEntry {
handler: RouteHandler;
names: string[];
}
export interface RecognizedRoute {
handler: RouteHandler;
params: Object;
isDynamic: boolean;
}
export interface CharSpec {
invalidChars?: string;
validChars?: string;
repeat?: boolean;
}
/**
* Class that parses route patterns and matches path strings.
*
* @class RouteRecognizer
* @constructor
*/
export class RouteRecognizer {
constructor();
/**
* Parse a route pattern and add it to the collection of recognized routes.
*
* @method add
* @param {Object} route The route to add.
*/
add(route: ConfigurableRoute | ConfigurableRoute[]): State;
/**
* Retrieve the handlers registered for the named route.
*
* @method handlersFor
* @param {String} name The name of the route.
* @return {Array} The handlers.
*/
handlersFor(name: string): HandlerEntry[];
/**
* Check if this RouteRecognizer recognizes a named route.
*
* @method hasRoute
* @param {String} name The name of the route.
* @return {Boolean} True if the named route is recognized.
*/
hasRoute(name: string): boolean;
/**
* Generate a path and query string from a route name and params object.
*
* @method generate
* @param {String} name The name of the route.
* @param {Object} params The route params to use when populating the pattern.
* Properties not required by the pattern will be appended to the query string.
* @return {String} The generated absolute path and query string.
*/
generate(name: string, params: Object): string;
/**
* Generate a query string from an object.
*
* @method generateQueryString
* @param {Object} params Object containing the keys and values to be used.
* @return {String} The generated query string, including leading '?'.
*/
generateQueryString(params: Object): string;
/**
* Parse a query string.
*
* @method parseQueryString
* @param {String} The query string to parse.
* @return {Object} Object with keys and values mapped from the query string.
*/
parseQueryString(queryString: string): Object;
/**
* Match a path string against registered route patterns.
*
* @method recognize
* @param {String} path The path to attempt to match.
* @return {Array} Array of objects containing `handler`, `params`, and
* `isDynanic` values for the matched route(s), or undefined if no match
* was found.
*/
recognize(path: string): RecognizedRoute[];
}
class RecognizeResults {
constructor(queryParams: Object);
}
// A Segment represents a segment in the original route description.
// Each Segment type provides an `eachChar` and `regex` method.
//
// The `eachChar` method invokes the callback with one or more character
// specifications. A character specification consumes one or more input
// characters.
//
// The `regex` method returns a regex fragment for the segment. If the
// segment is a dynamic or star segment, the regex fragment also includes
// a capture.
//
// A character specification contains:
//
// * `validChars`: a String with a list of all valid characters, or
// * `invalidChars`: a String with a list of all invalid characters
// * `repeat`: true if the character specification can repeat
export class StaticSegment {
constructor(string: string);
eachChar(callback: (spec: CharSpec) => void): any;
regex(): string;
generate(params: Object, consumed: Object): string;
}
export class DynamicSegment {
constructor(name: string);
eachChar(callback: (spec: CharSpec) => void): any;
regex(): string;
generate(params: Object, consumed: Object): string;
}
export class StarSegment {
constructor(name: string);
eachChar(callback: (spec: CharSpec) => void): any;
regex(): string;
generate(params: Object, consumed: Object): string;
}
export class EpsilonSegment {
eachChar(callback: (spec: CharSpec) => void): any;
regex(): string;
generate(params: Object, consumed: Object): string;
}
// A State has a character specification and (`charSpec`) and a list of possible
// subsequent states (`nextStates`).
//
// If a State is an accepting state, it will also have several additional
// properties:
//
// * `regex`: A regular expression that is used to extract parameters from paths
// that reached this accepting state.
// * `handlers`: Information on how to convert the list of captures into calls
// to registered handlers with the specified parameters.
// * `types`: How many static, dynamic, or star segments in this route. Used to
// decide which route to use if multiple registered routes match a path.
//
// Currently, State is implemented naively by looping over `nextStates` and
// comparing a character specification against a character. A more efficient
// implementation would use a hash of keys pointing at one or more next states.
export class State {
constructor(charSpec: CharSpec);
get(charSpec: CharSpec): State;
put(charSpec: CharSpec): State;
// Find a list of child states matching the next character
match(ch: string): State[];
}
} |
|
@Alxandr @wardbell @EisenbergEffect - here's the PR 👍 |
|
Yes great job cmichaelgraham :), |
|
Yeah really light the beacons when this is ready. Can't wait. |
|
Nice one! Thanks @cmichaelgraham |
|
"Shazam!!" indeed! Well played, sir. |
|
Any news on this? |
|
We've had official d.ts files for a while now. When you jspm install or bower install an Aurelia library you automatically get them. They are part of every release and always up to date with the source. We have a new validation process we are putting in place right now which will ensure that they are more accurate going forward. New releases coming in the next day or two. |
|
they even have code comments in them 👍 |
|
Sounds great, I thought that there were still news as the issue wasn't closed 👍 |
|
@cmichaelgraham The d.ts files keep getting better and better, but I have to set up a gulp task to copy them to my typings folder (to keep project organized, among other things). Do you plan on publishing them to TSD? |
|
Can't you set up your project's tsconfig file to simply look inside jspm_packages? |
|
@EisenbergEffect I could, but sometimes there are other .d.ts files within jspm_packages subdirectories that I don't want included. I've also had instances where, during an Aurelia version upgrade, folders of older versions were left behind which resulted in a handful duplicate .d.ts files. It's not a huge deal, because I needed to clean out those old folders anyway, but it would ease development for lots of us if we could use the defacto typescript definition file package manager. That being said, I assumed publishing to TSD could be incorporated into your build tasks, but I double checked and apparently that's not yet possible |
|
Same here. If I include jspm_packages all hell breaks loose - a ton of T2300 (duplicate identifier) are reported. |
|
Please have a look at our TypeScript skeleton to see how to configure things properly. |
|
You mean the Typescript Kit from Getting started? |
|
No, I mean the official TypeScript navigation skeleton. It can be found here: https://github.com/aurelia/skeleton-navigation-typescript But we will be moving all the skele variations into a single repo soon. |
|
Aaaah, there are samples floating around, easy to get confused. Looks promising, will dig into, thanks. |
|
@EisenbergEffect That link 404s now. Where do the skeletons live at the moment? |
and others
Are you guys planning an official Aurelia repo for the .d.ts files? I know there will be definitions in DefinitelyTyped or whatever, but the fact is, even DT contains broken or outdated definitions, and having up to date, official definitions would be very comforting.
The text was updated successfully, but these errors were encountered: