Will this be updated soon? Its almost a year since the last release.

aceymer commented 9 years ago

I love this project, but more and more of the modules are outdated. Will you add a new release soon?

trainerbill commented 9 years ago

+1. Love the project. What do we need to do to get updates? there are also 51 Pull requests.

Koslun commented 9 years ago

To state the obvious. Since the author and main contributor, DaftMonk, doesn't seem to have the time to go through all the Pull requests or contribute himself any more something of the following needs to happen:

Daftmonk gives someone more the authority to accept or decline PRs. If you want to be that person I'd suggest messaging DaftMonk directly.
Someone just forking the project and accepting the PRs themselves. Possibly trying to broadcast this to all lurking contributors. The fork could then also be merged back if DaftMonk does return in a more active fashion. If someone think they have the time for this I think they should just announce it and do it.
There's also just the option at looking at other generators, there are plenty. Here's an extremely comprehensive spreadsheet with other alternatives to this project made by @dancancro (https://github.com/dancancro): https://docs.google.com/spreadsheets/d/1r8rJy2Q5p5QORYKcye93UECwOlSgFL24c5fyF7dqhaM/edit#gid=1607194899. Discussed a little in this issue: https://github.com/DaftMonk/generator-angular-fullstack/pull/213. As I understand it the same person, @dancancro, is also orchestrating a weekly Google hangouts with some dedicated and experienced people on the issue of getting an even broader and better generator than this one by trying to gather up some of the different authors/contributors of all of these different generator project and get them to work together. After listening to one of the google hangouts on youtube I however have no clue if that is still the intention or what is happening, at all.

Hope that something pans out but still grateful to at least have this. Figured out how to update all non-dev dependencies at least so still saving a lot of time compared to starting from scratch. And like the structure from this generator a lot more than the other's. Only other that I'm hopeful for is: https://github.com/ericmdantas/generator-ng-fullstack. But it's still a long ways off.

dancancro commented 9 years ago

We're having a hangout today at 7:30 pm gmt. If anyone wants to participate I'll put the link in a comment here an hour before it starts. The topic will be "Reference app or CLI". I think this will be a good one.

So far, we have been pursuing a generator/command-line-interface to replace all the others, but that's not happened yet. So I propose a different tack of forgetting about making a generator at all and just making a real app with real features.

Here are my reasons why...

Have a look at this pie chart constructed from the points assigned in the spreadsheet.

Values Pie chart

This is entirely based on my subjective appraisals of the relative importance of the many different benefits. But if it is anywhere near accurate, and so far I haven't been flooded with objections to the point values, then it is saying how much more important a reference app (Implemented Functionality 27%) is than a generator (Generation+Scaffolding 7%). A reference app without generation/scaffolding can provide every other category of benefit by example.

Doing this instead of a CLI will make duty assignment pretty straightforward too: Jeremy, give the app some functioning charts... Tyler, give the app a functioning markdown text editor... Almog, give the app a functioning calendar. You can just go down the list and knock them off one by one. We can have really productive hangouts where we discuss the specific implementation approaches of real things - mass pair programming that will produce really great code others will use as a reference.

The master branch will have everything implemented in the MEAN stack and include documentation (generated from code comments) with each feature's readme.md to explain how it works and how to change it if you want to use different elements. The documentation will have a nice index similar to the list of benefits in the spreadsheet that directs them to the exact files or git commits related to the feature they want to have in their apps.

Concerns are supposed to be separated so these change instructions should be pretty short. Some variety can be accommodated using different pages of the same reference app and some can be accommodated using separate git branches of the same repo. If someone wants to contribute a MySQL/Express/Angular/Node version of the Account management feature, they can do so with a git branch.

That doesn't mean you'll need to mess with git branches to deviate in every way. Things will still be implemented with the greatest separation of concerns and it will be clear how to substitute what you want for what's in the app which has all been implemented in a modular fashion.

We will refactor everything and switch tools/components regularly as discoveries come about. We'll update the whole thing when Angular 2 and Angular 3 come out or, heck, even if we decide Go is better than JavaScript for a reference solver implementation in the reference app. This is something a beginner can help with too, so everybody can get involved. For example, if we decide to change all the 'MyController's to 'MyCtrl's, that's a straightforward operation a beginner can do.

And this handles change management somewhat too. Rather than us trying to find a smart way to automagically update thousands of cli-generated users' apps in all different situations without breaking them, users can go to github and run diffs to see what we did to update the reference app. Then do the same things to theirs manually, but relatively quickly and confidently without any mystery.

Most support can also be handled by the users themselves by just doing diffs between their app (that doesn't work) and the reference app (that does work).

By contrast, progress is at a standstill pursuing a holy-grail command-line interface to generate apps with no features, then change/update all of them flawlessly. It demands foresight and situation omniscience/accommodation that is just really hard to muster. It will require of its users faith and learn time that most of them are not going to give it, and most have not given to existing generators. And it doesn't produce an app with features. Unless they can find CLI-conformant modules built for every one of their desired features, users are still going to have to learn how to write code and/or wedge a non-conformant module into the CLI app in such a way that the CLI change management system still works.

The cart is before the horse here in my opinion.

To get a sense of how it would be with a real reference app, go here and imagine that this is not just a mock app, but everything actually works for real and comes with exquisite documentation and doesn't cost anything or have a closed license.

When confronted with a new real app assignment from a real client running a business, would you rather have that or a generator that may have at least one bug or incompatibility with your environment that causes it or its generated apps to not work for you? at all.

I also don't see a problem with having a few reference apps instead of one kitchen sink app if we can identify feature sets that should be grouped. We could even come up with some automation for our own use to produce a finite number of reference apps in different sizes and shapes that share common code. Then users could pick among those as the reference to use when making their own apps. I like that idea.

Once we have enough usage we can give some more thought to making a CLI to automate tedious things, but a CLI mostly reduces typing time and increases understanding time which is already the far bigger time sink. Both of them provide opinion and can contain automatic style enforcement, so on the matter of getting everyone to do things one way it's a wash. A CLI can handle language variety to the very limited extent of those features coded by CLI committers in multiple languages. Most feature modules are not going to be written in multiple languages. So people are going to have to do most of their translations themselves anyway.

I think those are all the arguments I can think of at the moment. Let me know if you see any flaws in them.

Dan

trainerbill commented 9 years ago

Thanks @dancancro. This is a tough decision. I can see benefits to both approaches. However, I think a reference application is taking a step back, and we will probably run into the same issues with updates etc. I think we are on the right track with this generator, but would like to see a combined project with the major contributors from the other MEAN generators. I know I would volunteer to contribute in anyway possible as this is the first place I go when developing a project. I do like the fact that you are trying to combine efforts into a main MEAN stack repo, and I know that not everyone is going to agree, so I am looking forward to the discussions that will be taking place.

Koslun commented 9 years ago

@dancancro Thanks for your input and considerable effort and think the general idea sounds very intriguing.

Personally only used the CLI needed to generate the app and plainly either did not trust or appreciate the other parts. As creating folders/files that follow the structure isn't hard enough to look at alternatives and because I associate great risk with automagically updating my project through the CLI, especially because I have projects with very low test coverage. So agree that it's easier to just look at the diffs/changelog and do it manually. Or even generate it anew with a lot of copy + pasting should there be any incredibly big breaking changes. Like going from 1.x to 2.x of this project.

Have actually looked into potentially buying themes like the one you linked or other similar ones like those available at themeforest.net. So definitely agree that the value proposition in having actually working versions. As long as we don't forget the Grunt/Gulp/Broccoli/future_build_tools. As I think making general build files is easier than most other features out there and the most useful thing about this generator.

Only a junior developer myself and don't know that I currently have the time to really participate in a very meaningful way down the line. I would however be interested in at least listening in on the Google Hangouts it's possible though.

dancancro commented 9 years ago

Here is the link to participate in the hangout. Hangouts allow up to ten participants. So if you'd like to just watch, you can use this other one to watch and comment through Youtube.

trainerbill commented 9 years ago

Did anything end up coming out of this meeting? I was playing around with MEAN.js and its alright. I still like this generator better. @DaftMonk do you want to provide someone else access to this repo so we can get some PR's merged?

honkskillet commented 9 years ago

Man, I just ran 'NPM outdated' on an installation and it spit out a pretty daunting list of outdated packaged. @DaftMonk, please take steps to make this become a group repo instead of a personal repo.

honkskillet commented 9 years ago

Including this scarily out of date package

Package              Current       Wanted   Latest  Location
jsonwebtoken         0.3.0         0.3.0    5.0.1   jsonwebtoken

Koslun commented 9 years ago

@honkskillet Luckily only a few things break if you update to the latest of everything. To name some annoyances:

Virtually all Express calls become "deprecated". They still work but a warning will be printed to console. Quite a simple fix but have to be done to every single Express call if you never want to see it again.
Updating the mentioned jsonwebtoken package along with express-jwt will make it so that exceptions are thrown whenever authentication fails. Won't crash the application but does give more spam. updating the exception throwing line with:

validateJwt(req, res, function(err){ 
if(err) return res.status(401).send(err);
        return next();
    });"

sendfile in routers.js fires deprecated warnings. sendFile doesn't do the exact same thing, from my experience at least. Changing the callback to the following fixed it for me:

app.route('/*')
    .get(function(req, res) {
      res.sendFile(app.get('appPath') + '/index.html', { root: config.root });
    });

Are also other annoying bugs like an extra address being published in express when in production mode. Causing the annoying bug that going to localhost works but not to localhost/*. Only discovered this in production and just assumed it was due to a faulty Nginx configuration.

Would still however say that this generator compares very favourably to its competition. All kinda depends on your needs and skillset. To me having to change the Grunt file feels like the greatest hurdle.

Koslun commented 9 years ago

@trainerbill I just sat in on the Google Hangouts discussion on April 16, 2015 with @dancancro and a few others like Igor from the Angular team and watched one more time.

The outcome of the meeting was a general consensus to create a project with a CLI. The idea was for participants to look over a CLI tool that took after the Ember-CLI somewhat: WrenchJS. With Igor also seeming quite interested in putting up something officially under the Angular organisation on GitHub. Igor also explained a bit about the Angular team making an example app for Angular 2.

After that I don't know what happened other than that Igor, and at least I as well, were too busy to make it for the follow-up meeting. The document detailing previous Hangouts and lots of other notes has however been updated, but not since 13th of May now. Coming in at a bit over 40 pages I'm not quite sure what has changed either. I don't see an update in the meetings that have happened so might just be general ideas.

Maybe only @dancancro can shed some light on what's happening and what to expect.

dancancro commented 9 years ago

Hi @Koslun

There isn't much to report at the moment. The last couple of hangouts we talked about differences in reference app and CLI purposes. I sent out some ideas but didn't get any feedback yet. I'm afraid that my motivational and leadership powers just aren't as sharp as they need to be to unite volunteers with different visions and limited time. I reckon that few people have that much charisma. I haven't seen Igor in a while and I am not on the Angular team so I can't really say what priority an Angular CLI is for Google. It seems to be important. I imagine that getting Angular 2.0 out is a much higher priority.

I've turned my focus back to the spreadsheet which is something I, as a novice, can actually do. It may or may not have slowed the multiplication of approaches (it's hard to tell), but can at least reduce the time people spend choosing among them. At the moment, my attention is on the Angle templates which have a number of good things going for them as you can see on the starter trade-offs worksheet.

To help the spreadsheet help people, I've created questionnaires to collect knowledge which will improve the quality of the spreadsheet data and make development better for everyone. If you know anything about any web technology (and I know you do), please take a minute to visit this page and share what you know.

Technology Questionnaires

dmarcelino commented 9 years ago

Regarding this topic, it may be useful to read issues #801 and #884 which are related.

I also suggest looking at generator-ng-fullstack, it's inspired in generator-angular-fullstack and @ericmdantas has been quite active.

Koslun commented 9 years ago

@dancancro Pity about the meetups. Do agree that Igor and the Angular team's priority probably is about just pushing out Angular 2. But do also agree that they do seem interested in making some kind of generator. At least Igor seemed inclined to do something. While additionally @btford at Angular was the main contributor to Yeoman's official Angular generator .

If we do end up making one generator-to-cure-them-all I do see Angular as being in the centre. Most generators I see are already doing this anyway. With either some custom CLI or layer on top of databases or Express. So think it would make sense to put it through the Angular team then if possible. The big downside I see with wedging in server stuff into a generator driven by the Angular team is that I don't trust them to actually keep all the server stuff up-to-date. Not that they aren't fantastic developers I'm just not that convinced that they're that committed to keeping it alive. So figure it could just as easily go the same way as this project.

So like some others have argued before I think figuring out a good way to compose the generators into client and server would be a good idea. We kind of separate most of client and server code anyway so might as well separate the generators imo. The only tricky part I see is different generators agreeing how login and maybe some basic CRUD should work. I think most client-only generators would be a lot more useful if they did this though. While all the server generators could focus more on making a stable server generator or have less pressure and just do one thing. Like using Go.

The ideal would still be if everyone just worked on the same repository to make an infinitely configurable generator for all technologies and configurations there are. However as I don't see it happening I think just splitting up the generators into smaller parts and trying to solve less problems might be a step in the right direction.

Koslun commented 9 years ago

@dmarcelino Good links, #801 in particular points to more interesting reads, #884 just culminates in the generator you just linked. Recommend @dancancro 's spreadsheet, which he linked above. A lot more comparisons there. I find the "Starters" sheet in it particularly useful.

Am a bit interested in @ericmdantas's generator-ng-fullstack. Been following it since he decided to create it in that thread. Unclear how much is left for it to actually meet feature parity with this generator or what is actually working and what isn't but can see that he has put down a lot of work on it.