Proposal: Move out DoneJS Dependencys to Generator

[frank-dspeed]

I Engineered a lot on new versions of the donejs cli and donejs. As a passionated developer, I determined that the dependencies for donejs add app shouldn't be in this project at all. They should get added to the generator. This way projects are easy updatable and all that via installing a new generator.

This way we could move out all the code to other generators. For example, parts like donejs add app, donejs add plugin and that to the generator we give it a bin "add". This way we can strip out all parts from donejs cli that have to do with the generator and can then do donejs add and it will run the add binary from the generator-donejs.
This way we are more cool more stable and easyer update able.
We can also then implement other alternative installers like Yarn as well.

greetings.

Hope that makes sense :D

[justinbmeyer]

@frank-dspeed Thanks for the passion!

Unfortunately, I'm not sure exactly what you mean. I think something must not be coming through in the translation. I cleaned up your comment to make more sense.

Having updated it, I'm still not very sure what you mean.

We've already proposed moving some of the donejs add app behaviors that get installed into other donejs add X generators in this issue: donejs/donejs#540

Are you recommending something other than that?

Some other thoughts that I'm not sure are relevant:

• yeoman already exists, we don't need to be another generator framework.
• DoneJS is an opinionated framework designed to provide a particular feature set.
• you can build something like a DoneJS app manually via npm install steal, npm install can, etc

If you literally mean:

dependencies for donejs add app shouldn't be in this project at all.

Dependencies should not be loaded from the generator. DoneJS generators will take on a life independent from an application. 3 years from now, a donejs app might look very different. Upgrading a generator will not be able to actually update the application.

[frank-dspeed]

@justinbmeyer
At Present: all relativ from github.com:
donejs/donejs does handle donejs add via global bin
-> it calls a internal init function that creates a dir and does installation of the donejs/cli
-> then it fires the current installed donejs/cli
-> the donejs-cli will installIfMissing the generator and
-> fire the generator.

MyProposal:
donejs/donejs installs a global yoman generator called generator-donejs
-> that gets used via yo donejs add
-> that can be then used also via donejs/donejs add translated to yo donejs add
-> the generator will create the project dir and install choosed donejs-cli in project and finish all the rest

so all configuration about the project goes into the generators

hope that makes sense

the main change is to strip out donejs-cli out of the process of creating donejs-projects.
because it is simply a optional dependency at present donejs-cli's package.json gets used for adding dependencys thats realy bad i think we realy should move that to the generator.

this way also any yoman user can do run: yo and install donejs generator via the yo installer and then do
yo donejs i think thats realy importent

it also enables and fixes path issus:
donejs add app bla/project relativ will work
donejs add app /home/bla/project absolute will work

also with all plugins and components and that

it also enables updateing the generator to detect yarn or npm and use the right as also give config flat for that without the need to add yarn support to donejs-cli only donejs/donejs and the generator would install packages.

then all generators get package named generator-donejs-cordova and so on this way we can make all accessible to yoman community and more comfortable to the donejs community

the generators all get a versions folder with the definitions for every version we can also put migration into that if you like.

Imagin automigrating from donejs 2.3 to 3

yoman offers auto update for generators so they will always have the newst versions ;)

[frank-dspeed]

and by the way i have that ready i can upgrade the generator-donejs to work indipendent from donejs/donejs

[matthewp]

Hey @frank-dspeed a lot of this sounds really good.

It sounds like you are almost proposing getting rid of donejs-cli though, is that right?

One key thing that we did when designing the cli is make it so that if you install DoneJS 0.8, when you run donejs add app you will always get a 0.8 app. We did this by making the donejs-cli versions match the major/minor versions of DoneJS. Any proposed changes will need to account for that.

[frank-dspeed]

@matthewp they are accounting that at present and yes your right i am planing to put all functions into donejs global bin:

  New Design: donejs/donejs/bin/donejs
  can find current Project
  can run binarys localToProject
  can run generators localToProject
  can run global generators
  can installIfMissing localToProject
  can installIfMissingGlobal Global
  can run npm scripts localToProject

also it will account that via the generator the new donejs bin will handle add over to yoman and yoman will see if there is a installed version else offer all versions so you can choose one for your app it is also able to upgrade your app so it can find in current Project Dir 0.8 and can upgrade to can3 💃

the new generator takes all parameters donejs add did handle + new once
it also finds the current projectdirectory via yomans own methods.
it will ask questions and then generate the directory and add package json else it will integrate package.json as defaults into questions and so on the overall flow will be realy nice you will see it i already saw it 💃

[frank-dspeed]

@justinbmeyer @matthewp did i say it solves all existing issus listed here :) i only need your go then i stop working on my fork and rename all in it to donejs and make a pull request against github.com/donejs/donejs

and github.com/donejs/generator-donejs

[frank-dspeed]

*** Update ***

# feathers-cli already uses yo and so we could also integrate directly into feathers project
warning feathers-cli > generator-feathers > cross-spawn-async@2.2.4: cross-spawn no longer requires a build toolchain, use it instead!
warning feathers-cli > yo > fullname > npmconf@2.1.2: this package has been reintegrated into npm and is now out of date with respect to npm

[phillipskevin]

I think that moving the responsibility for installing app dependencies into the app generator is a good idea. Currently, donejs-cli passes this list to the generators. This is used by the app generator and the plugin generator to write out a package.json file for the generated app/plugin.

I think the only reason for this is what @matthewp mentioned above (#63 (comment)).

But generator-donejs can behave the same way. If you have DoneJS 1.0 installed globally, running donejs add app will install generator-donejs@1.0 so that the correct dependencies will be used. Or is there something I'm missing here? @matthewp @justinbmeyer

[frank-dspeed]

@phillipskevin yes your missing something :) but first of all 👍 so now the Real Solution that i already did tested and i am using it in production since many month :).

IMPORTANT NOTE GENERAL: Yeoman generators are made to be installed Global! and designed to get updated via a internal auto update function of Yeoman

donejs-cli offers:
- using node_modules/.bin/* via donejs // this can easy be done via global donejs
- using generators via yeoman-environment relativ to project/node_modules/ // can easy be done via global donejs but should be depricated because its agains Yeoman usage Best Practice
- It has a list of packages and versions right we can move that to the generator and so enable it to get installed global and it works like a charm also update able via Yeoman autoupgrade and i do version pining via a extra fild in package.json i store all my donejs settings in it in a { donejs: {} } Object
- installIfMissing // can be replaced by simply run yarn install or npm install as both will only update if aviable or will detect already installed packages so can be deprecated.


i would propose to:
do a inidpendent generator-donejs that loads version related sub modules with custom repos so we end up
the generator-donejs can list all versions and let the user choose as also offer default.
it can detect also if there is donejs-cli in project directory and what version it has.

Repos:
generator-donejs
donejs-migration-1.x-2.x
donejs-version-1.1.0
this way we can even update with the semver style the projects.!

[matthewp]

@phillipskevin What would be the advantage of putting the list in the generator?

The idea of donejs-cli is that you shouldn't have to update the global donejs very often (just major version changes), and by having a local node_modules/.bin/donejs this will ensure that all members of a team are using the same donejs version regardless of what global version they are using. The global donejs is meant to be a very thin layer that just calls into the local donejs. Adding features to the global donejs would go against that.

Getting rid of donejs-cli in favor of generator-donejs doesn't solve that problem, donejs-cli is about more than just donejs add app/plugin.

[phillipskevin]

The purpose of moving the app dependencies to the app generator is just to keep the responsibility in one place. Also, I think generators should be responsible for installing their own dependencies.

This idea came about while working on donejs-documentjs. To remove documentjs from an app generated with donejs, I had to change donejs-cli to not install documentjs when creating a new app and change generator-donejs so that the .md and documentjs.json files are not created.

I thought about creating another issue for this since the discussion on this one is much broader than what I'm proposing, but I wasn't sure if that would be even more confusing since the title would be nearly identical.

[matthewp]

@phillipskevin Ok, if this is just about where to put the versioning information consider that the versions are used by:

• donejs add app, which as you say would be more maintainable if it included the version in generator-donejs.
• Upgrades. Currently this is done manually by devs looking at the donejs-cli tag's package.json and seeing what to upgrade. However we've talked about adding some type of donejs update or donejs upgrade utility, see donejs update donejs#535

Given that the version numbers are used (potentially) by more than one tool, I think they should remain somewhere neutral.

I wonder if it would make sense to have a donejs-versions repo which contains JSON files like 1.0.0.json, etc. and then each tool would pull from that to get the version numbers of individual packages.