Proposal: integrating efforts

[dsebastien]

Hello,

I've seen @IgorMinar 's presentation of angular-cli & @pkozlowski-opensource talk about ES2015, modules, System, JSPM etc while at AngularConnect in London and found the idea of Angular CLI to be pretty similar to 2 small projects I have created recently:

• https://github.com/dsebastien/modernWebDevBuild
• https://github.com/dsebastien/modernWebDevGenerator

Since @IgorMinar mentioned that community participation was welcomed, here I go! :)

I don't know how far you guys are willing to go with Angular CLI and how prescriptive you want to be, but maybe some ideas below would be worth discussing.

Here's an overview of my projects:

ModernWebDevBuild is based on Google's Web Starter Kit (heavily tweaked/enhanced) and can be used to:

• transpile ES2015 to ES5 w/ sourcemaps
• transpile TypeScript to ES5 w/ sourcemaps
• transpile SASS to CSS w/ sourcemaps
• check JS/TS code style & code quality (requires JSCS/JSHint/TSHint config files to be present)
• serve the app with support for multi-device sync (using BrowserSync) and watch tasks that constantly do all the above without stopping when an error occurs (continuous flow for the developer with useful feedback)
• generate production bundles for CSS/JS/HTML/images
• serve the production build (without watch)

ModernWebDevBuild has minimal requirements regarding the project structure and the presence of some files, but I think this is positive as it provides a good starting point for larger projects.

There are some major features still missing such as testing integration, configurability & extensibility, but I think that it is already useful as is.

ModernWebDevGenerator is a Yeoman generator that integrates the use of ModernWebDevBuild (which is just one npm dep) and generates a working project starting point. It integrates some code organization/design guidelines for structuring the application components, pages, etc in a logical manner while considering componentization as first-class concept by regrouping all pieces of a given component together (e.g., component class, component styles, component tests, ...). Given that the build is flexible enough, it doesn't prevent users from reorganizing as they wish.

Both projects are pretty opinionated thus I suppose that there are choices in there that you wouldn't impose on your users (e.g., Gulp, SystemJS, JSPM, SASS, ...), but maybe the feature set and/or necessary extensibility could be integrated within Angular CLI and/or Angular Toolkit?

I think that:

• having a recommended project structure & organization guidelines is beneficial at many levels
• having live reloading with multi-device synchronization support is great
• having continuous transpilation, code compilation/quality/style feedback (without breaking) is awesome for developer productivity
• having a "standard" way of building projects (from dev to prod) is tremendously useful for larger projects and integration with CI & CD solutions
• having an extension system to let the community cater for its own needs is a must (e.g., CSS copy by default and a SASS plugin for those who want that)

Most importantly, I think that having a Google-backed basis for all this, with enough anchor points for extensions would be awesome for larger projects requiring more than Plunker :)

By having this one central piece in the Angular "build puzzle", it might be easier to make related projects evolve in the good direction; for example for now TypeScript can look up modules in node_modules but is totally incapable of doing the same with jspm_packages, although that could be really nice.

[dancancro]

Hi @dsebastien

I collect information about projects like this to help people better understand the differences between them. If you or anyone else is interested in shedding light on what distinguishes your project or angular-cli, please visit this site to do a questionnaire about it. I refer to things like your project and angular-cli as "Application Starters" for lack of a better word. "Stack" and "generator" are probably more familiar. The questionnaires are really long so don't feel compelled to finish them.

From data collected through questionnaires and other sources, the system generates head-to-head trade-off reports between pairs of technologies. You can view those here. While viewing a report if you see any errors, you can submit corrections using forms in the report. So that's another way to share what you know.

[IgorMinar]

@dsebastien thanks for reaching out and sorry about the delay.

My plan is take some time after Angular 2 beta is out to write down all my thoughts on all things cli.

In the meantime just briefly: There are reasons why we decided to try the ember-cli path rather than yeoman path. The main one is that yeoman is a scaffolding tool that can be customized via generators, while ember-cli is a platform/ecosystem of addons that complement each other and can work in unison. Achieving the same with yeoman is pretty tricky because it was never designed for this.

[dsebastien]

Hello @IgorMinar. Indeed, ember-cli seems a much better fit for extensibility than Yeoman; I'm currently only using it for the initial project creation. My current plan is to create a separate (global) package to act as CLI, which could also help me avoid the need for systematically installing 100+ dependencies in the project (which takes forever with npm).

I'll try and help when there are more concrete plans for angular-cli. Ultimately I prefer to have my needs covered either through angular-cli or extensions thereof than maintain my own isolated island :)

[IgorMinar]

Awesome. I'll write up my thoughts as a design doc or a blog post and will
link it here. After Angular 2 beta.
On Sun, Nov 22, 2015 at 11:55 PM Sebastien notifications@github.com wrote:

Hello @IgorMinar https://github.com/IgorMinar. Indeed, ember-cli seems
a much better fit for extensibility than Yeoman; I'm currently only using
it for the initial project creation. My current plan is to create a
separate (global) package to act as CLI, which could also help me avoid the
need for systematically installing 100+ dependencies in the project (which
takes forever with npm).

I'll try and help when there are more concrete plans for angular-cli.
Ultimately I prefer to have my needs covered either through angular-cli or
extensions thereof than maintain my own isolated island :)

—
Reply to this email directly or view it on GitHub
#49 (comment).

[SBoudrias]

Hey, a note about Yeoman.

Even though you want to go the angular-cli way rather than combining tools through a generator (and that's fine), Yeoman is an easily embeddable tool.

Your community would really benefit from still having the scaffolding parts of your cli tools done by Yeoman. If published both as the cli tool and a generator, you'll allow other author to extend and compose the angular2 generator on top of different backend system (for example generator-angular-fullstack) or with differents styling frameworks, etc etc.

Integrating a yeoman generator in your own cli is actually a very easy thing to do: http://yeoman.io/authoring/integrating-yeoman.html - I'm sure @eddiemonge, @Swiip, @DaftMonk and @kingcody would be happy to give you a hand to get an angular2 generator bootstrapped.

[Swiip]

Yeoman community is definitely already working on generators for Angular 2. @zckrs and I already have a walking skeletton of an Angular 2 generator working both with Webpack of SystemJS / JSPM: generator-fountain-angular2. It still miss the switch between Babel or TypeScript but it’s on what I’m working right now.

I think Yeoman is the best platform to address seed projects and component generation, it’s designed for that and offers lots of built in tools to do it efficiently like inquirer or mem-fs-editor.

Yeoman is perfectly capable to handle a coherent ecosystem of generators. I think we prove it through the very high number of options in generator-gulp-angular. But there is more, there is dedicated features for that in Yeoman like generator inheritance and composition. In fact FoutainJS is exactly based on this concept and is already capable to compose 12 generators to generate very differents apps. (README, DESIGN)

Finally, I must admit I’m not a fan of the "framwork-cli" approach. It implies too much that you have to use the framework tools to use the framework and doesn't promote community. The best way to start an Angular 1 project as always been to use Yeoman and that’s great. The Yeoman community created a lots of great project (like mine I hope but also :) angular-fullstack and jhipster.

[dsebastien]

The scaffolding part of the story is nice and necessary to quickly get started but it isn't enough.

I think that front-end apps need generic & pluggable build systems that cover the whole spectrum from transpilation to quality/style checking, through testing, code coverage checks etc.

Having a project generator drop a kilometer-long gulp file that won't be kept up to date/versioned just means that each project will get a different build evolving differently in each project.. On the other end it just sounds just plain stupid to go about and create project-specific gulp tasks that more or less do the same, but it feels like it's where the front-end world is still at nowadays.

IMHO, the build itself should be kept separate from the actual projects and be versioned like any other dependency; this is why I've created the "modernWebDevBuild" project. The build should be flexible enough to support different project structures and to allow for different tools to be used (e.g., sass vs less, angular vs react, ...).

I dream of a tool for the front-end world that would be a mix between a scaffolding tool and a build tool (let's call that a front-end CLI). Such a tool should be powerful & pluggable enough to be both generic (i.e., support a common set of tasks) & support framework-specific tasks (e.g., like angular-cli which provides an easy way to scaffold components, filters).

My feeling is that angular-cli is nice for the Angular world and will be cool, but that in the long run, the whole community would benefit much more from a more general solution.

Of course it's easier to say than do ;-)

[Swiip]

I work with seed projects for a while now and I'm still convinced that the build process is THE thing in web app dev where people needs to get started with a good configuration but can't be abstracted because people has too many different needs.

Grunt tried and results in programming with JSON, Webpack, I fear is doing the same today (even if I use it because it's very powerful). Before that Maven tried and failed too (IMHO). It's why I'm so much tied to Gulp because you don't configure your build, you develop it with code.

It's also why someone like me who really believes in abstractions in development is working on a code generation tool. Because I'm still convinced people should start with a good tooling environment but has to understand it and modify it when the project grows.

If you want to hide everything in a lib or a generic cli, just take Webpack or Brunch but I think you'll end up with a JSON nightmare like many others.

[SBoudrias]

@dsebastien my point really was that Yeoman is pluggable. Angular-cli will need a scaffolding tool, and you shouldn't create your own; instead just wrap Yeoman.

Then I was saying the scaffolding part should be published as it's own composable generators so it can benefit the whole community if they wish to add and bind it on top of specific backends systems.

I totally get the point of going with a tool specific cli tool - but I just want to make sure you're not losing what the Yeoman community already provide for angular users. IMO that's a mistake the ember team did.

[Swiip]

@SBoudrias just helped me to focus on the point. I lost myself in philosophical thought :)

Yep, as a user of Yeoman API: it's a great scaffolding tool and you'll benefit both of it's API and community.

[dancancro]

@SBoudrias I believe the plan is to adopt the ember blueprints approach to scaffolding. Also for what it's worth, here are some notes from discussions and Google hangouts that were had around the goal of uniting the different projects and among other things producing a CLI.

[NathanWalker]

@Swiip Due to what I encountered here:
#222

Curious if yeoman has or is planning on providing similar ability to generate files with more flexibility around the location. The benefit to the file generation is you get (.css, .html, .ts, and .spec) scaffolds which is very helpful. In addition, I think it would be nice to be able to point a generator at custom templates so if your application used custom decorators for components lets say, the component generate would use the component template you specified for your application 👍

[Swiip]

In generator-gulp-angular we propose to configure the main directories (https://github.com/Swiip/generator-gulp-angular/blob/master/docs/usage.md#yo-options) but still, the template app inside is quite fixed. But most of the users are looking for a directory structure.

In FountainJS, we want to propose at least 2 options: a minimal hello world where there is no structure just the minimal configuration and a more complete example which can help juniors to find their start.

[NathanWalker]

Thanks for the info @Swiip I'll look forward to that and continue further discussion over on the Fountain repo.