Typescript support for generator-angular #313
Conversation
* generate parts of Gruntfile.js, gitignore based on selected language * set language in package.json for subgenerators to reference (for subsequent runs of the subgenerators) * passing user choices to subgenerators (for the initial run of the subgenerators hooked from the main generator) * reformatting of lodash conditionals that reads clearer yet still preserves whitespace * overrideable configs templates (for things like backend URLs) * template partials preloaded for dist * controller and service generators FUTURE WORK * filter and directive generators * ask user for top level module name * revving of templates.js (with hopefully an elegant solution to the two pass problem) NOTES I could not find the intended way to pass user choices down to the subgenerators that are hooked from the main generator. The pattern for processing user choices seems to be setting the values on the generator object itself, which are then made available in the template using, presumably, a with block. To follow this pattern for subgenerators, I needed a struct with user choices to be available in the constructor of the subgenerator. Using the options-options during hook registration, with a by-reference object in it that later gets populated with user data, was the only way I could manage it. It is conceivable that using this.env.options is the idiomatic way, and it has one benefit of not differentiating where the choice comes from, question-answer session with the user, or cli arguments. The problem with it, though, is that it completely obscures data flow through the program, and makes it impossible to trace where values are coming from. I am a strong proponent of explicit data flow. Also reformatted _bower.json so that the conditional expression appears on the same line as what is being conditionaly included, while still preserving the white space properties (i.e. no empty newlines are added for false conditions).
|
What about this, guys? I'm really looking forward to use that! |
|
Yeah, Brian et al, please let me know if I can do anything to move this forward. I'm really not looking forward to merging in all the changes that happen in master while this PR is pending, so it would be awesome if we could move things along. -a |
|
Brian just came back from his vacation and is still a little busy. This is definitely a decision too large for me to decide. I definitely like the idea of having a generator that scaffolds out AngularJS + TypeScript, but I'm a bit hesitant to the idea of including it with the main |
|
Thanks for the update, Pascal. For what it's worth, as far as I know CoffeeScript is in exactly the same position as TypeScript, yet it was baked into generator-angular from the start, in a way that you could only manually remove the coffee parts after you finished scaffolding the project. This change makes both CoffeeScript and TypeScript optional. We are already incurring a maintenance and complication tax because of CoffeeScript, with all the scriptSuffix code, and the coffee-specific pieces of code that should have (in my opinion) been optional. So if we were to go the TypeScript-specific separate generator route, I would suggest considering moving all the coffee stuff out into its own generator as well, and that way generator-angular can be nice and clean. Either way, I want to get this angular-typescript stuff into the hands of developers, so I'm willing to contribute more design/code. Looking forward to sorting this out. |
|
Can you guys please offer at least some insight into what's happening with this PR? -a |
|
Yes!!, @btford please take a look at this. It would be awesome to have typescript generator available to us.. |
|
Is anyone looking at this anymore? We are using our own generator for typescript support which is also a fork of this one but it would be nice to have a standard one. I think TypeScript is getting enough attention within the angular community to get official support on this generator. |
|
i think the problem is not a lot of people know about typescript at the moment so reading/testing it is a bit harder. Also, before you know it there is going to have to be a dart implementation and whatever new JS variant comes out. Having said that, @anchann could you please rebase and merge conflicts as at lot has changed since this originally landed. |
|
@eddiemonge sorry, not going to rebase and merge conflicts. Two months ago I sunk a very sizeable chunk of time into this, only to get silence back from the official maintainers. A rather sad introduction to the open source world. I can understand that my changes may have been crap, I may have implemented things differently from what the maintainer desired, or taken the Google-centric generator into the undesired Microsoft direction, but responding with silence is just plain rude. So unless there is serious, committed interest from them, it is not worth any more of my time. |
|
I'm sorry you feel that. I'm pretty sure it wasn't the teams intention to make you feel like that. I know from doing OSS for awhile now that it can get frustrating but at the same time you got to remember that most people doing OSS aren't doing it as their main job. Most aren't even getting any financial gain out of it and are doing it because they like doing it. With this PR specifically I know its not super popular and the team has probably been hesitant to look at it for a number of reasons, some of which may be:
You as a contributor to OSS have to be patient, it may take a long time for a PR to land or be rejected. I know I have some PRs in the angular.js project that have sat for months but there is nothing I can do other than keep the PR fresh and up to date on the off chance the team gets to it and wants to operate on it right away and thus can without having to have me do something. Sometimes though it does take a ping to remind people that something exists and needs attention, like what @santialbo did. It got my attention and that's why I asked for those changes. |
|
What you say makes sense, no argument here. I have two comments. Anticipating what the magnitude of the change will be like, I reached out to the maintainer by email, inviting him to look over my project in which I was using angular with TypeScript, and exploring other useful features. He expressed interest in adding TypeScript to generator-angular, and encouraged me to open an issue. Having gotten no more response since them, I emailed him again, and this time he encouraged me to submit a PR, saying he'll look it over. It was with that encouragement that I spent a considerable amount of time building out this change set. As far as being patient and persistent as an OSS contributor, to me it boils down to the value of time invested compared to the value of the contribution multiplied by the probability of landing. I personally think that TypeScript is the best thing that's happened to web development since angular, and anybody still writing code in JS or CS is insane. Every time I get a TS compile error I rejoice, because without TS it would have been a difficult to trace JS error. The whole yeoman project was about moving the web forward, and at the time I felt that it was my duty to help where I can. Since then, the infrastructure work in setting this stack up was finished, and I've moved on to actually building useful things with this stack. The value of my time shot up since now I'm working on actual feature code, while the probability of landing is still basically undefined, which is as good as zero. |
|
@eddiemonge didn't realize you have an official role in the project. That's good to know. Before we proceed, let me ask you: do you think it's even a good idea to have multiple languages supported by generator-angular? Are generator-angular-typescript and generator-angular-coffee perhaps better off as their own stand-alone generators? The more I work on this stack, the more stack-specific patterns I discover, patterns that add structure and remove guesswork from the project. The use of TypeScript modules to namespace various parts of the project is one example. I would like to include it all in the generator, but having this stuff interspersed with conditionals so as to keep the pure-JS version usable seems like a testability nightmare. So perhaps the right way to proceed is to remove coffee from generator-angular, make it nice and slim and clean, and have generator-angular-coffee and generator-angular-typescript be independent projects. Some utility code may be shared between all these through a separate submodule. Thoughts? -a |
|
Having added support for typescript to generator-angular myself too, I couldn't agree more with @anchann. |
|
Honestly I have mixed thoughts on it. On one hand, yeah its a testability/maintenance nightmare to support multiple Another hard thing to consider is switching between JS and a precompiled language can be super hard. If its not setup with that in the beginning, switching consists basically of creating a new project using that and then merging it in. Well thats how it should be but in reality the project is basically setup with coffeescript in mind and switching to it from pure JS is relatively easy. Downside of that is that pure JS build arent as clean or as simple as they should be. |
|
I for one would love to see this happen. Our group is about to start with an angular/typescript stack and a typescript generator would make our lives easier. |
|
We're working on making Yeoman generators more easily extensible in the future, so that if you do have separate generator projects, keeping them in sync with a parent will be more trivial than it is now. That said, language support is something I agree should be part of the main/original generator where possible. |
|
I need to read about typescript to understand this one. One question I do have is why is there ts and js file? Is that how typescript works? |
|
Yes. It's the same as coffee script. However, .ts files accept raw javascript as well. |
|
@eddiemonge can we consolidate what we want to do regarding #313 and #539? We currently have a few different PRs and issues related to it open. Would be great to close ones that are stale which we won't be moving ahead with. |
|
@addyosmani I need someone who knows TS to do a review of both to see which is better. Or I need to spend a few days picking up the basics. |
|
@anchann @luisrudge @santialbo @jedmao I would love to typescript support into the angular-generator, would one of you have time to help @eddiemonge with a review of this vs. #539:
|
|
If people doing the review could review the files in the |
|
I'll review it tonight. I'm on gmt-2 Enviado pelo meu Windows Phone De: Eddie Mongemailto:notifications@github.com If people doing the review could review the files in the Reply to this email directly or view it on GitHub: |
|
Just be aware there are now two TypeScript PRs open, this one and #539 |
|
Closing in favor of #539 |
Hey Brian and other maintainers,
I wrapped up a bunch of changes to get typescript working out of the box with generator-angular. It's not feature complete, but there's definitely enough there to be very useful to anybody who wants to build an angular app in typescript. I'll be happy to continue porting other features that I have in my personal stack, but first wanted solid confirmation that there is interest in what I'm doing, so that my time is not wasted.
I tested backwards compatibility by diffing the directories resulting from running yo on my branch and on master. Also tested
grunt serverandgrunt server:distfor both typescript and javascript versions. Let me know if you guys have some more systematic approach to regressions.A bunch of notes about my changes are below. Obviously there are many ways of accomplishing the same goals in code; I tried to make sensible choices based on what I could deduce from the code. Happy to discuss and implement changes.
Also, there's a small changed necessary in generator-karma to get unit tests working. Submitting that shortly.
Cheers,
-anchann
(for subsequent runs of the subgenerators)
of the subgenerators hooked from the main generator)
preserves whitespace
FUTURE WORK
two pass problem)
NOTES
I could not find the intended way to pass user choices down to the
subgenerators that are hooked from the main generator. The pattern for
processing user choices seems to be setting the values on the generator
object itself, which are then made available in the template using,
presumably, a with block. To follow this pattern for subgenerators, I
needed a struct with user choices to be available in the constructor of
the subgenerator. Using the options-options during hook registration,
with a by-reference object in it that later gets populated with user
data, was the only way I could manage it.
It is conceivable that using this.env.options is the idiomatic way, and
it has one benefit of not differentiating where the choice comes from,
question-answer session with the user, or cli arguments. The problem
with it, though, is that it completely obscures data flow through the
program, and makes it impossible to trace where values are coming from.
I am a strong proponent of explicit data flow.
Also reformatted _bower.json so that the conditional expression appears
on the same line as what is being conditionaly included, while still
preserving the white space properties (i.e. no empty newlines are added
for false conditions).