Split up generator-donejs

[phillipskevin]

I suggest we separate generator-donejs into separate generators:

• donejs-app
• donejs-plugin
• donejs-generator
• donejs-component
• donejs-supermodel
• donejs-module

and a utility project donejs-plugin-utils (or something like that) for the utility functions currently in lib/utils.js.

The main benefit of this is that dependencies that are only needed by one of the generators would not need to be installed with donejs add app. Here's a list of those dependencies:

generator	dependency	size
component	can-view-autorender	570 KB
component	done-component	1.9 MB
component	can-component	1.8 MB
supermodel	can-fixture	3.9 MB
supermodel	can-connect	3.8 MB

Install times before removing these:

Analyzing 22 dependencies...
...
Total time (non-deduped): 2m 5.7s
Total size (non-deduped): 175 MB

And once they're removed:

Analyzing 17 dependencies...
...
Total time (non-deduped): 1m 50.9s
Total size (non-deduped): 163 MB

Another benefit of doing this is that it would make the donejs-cli code a bit more maintainable because it would remove the special casing for generator-donejs and these generators would be added just like anything else using donejs add.

[matthewp]

There are some dependencies that should be installed with donejs add app even if they could theoretically be deferred. can-component, for example, is so core to how you build donejs apps that it would be very strange to not have it installed when initializing a new app.

[phillipskevin]

What if your app is only using donejs-custom-elements? Or donejs-react-view-models?

Obviously, these don't exist, but it's possible a year from now that someone using DoneJS would not need can-component.

I don't see a problem with installing can-component when you run donejs add component.

[matthewp]

That's a fair point, but what would be core then? Just about everything could potentially be deferred. Could even have a donejs add ssr if we wanted. There's a balance there has to be, not sure what that is.

[phillipskevin]

My initial response to the question would be: "core is anything needed to generate and run an app in development and production".

But I think we kind of have to take it on a case-by-case basis. Making the changes proposed here would not affect the guides at all. Making a donejs-ssr would add more steps and explanation before the user could start the app in development mode and see the "Hello World!".

[frank-dspeed]

I think we should go even farther I just got yesterday added to the NPM Package for "generator-canjs" shouldn't we take over this to canjs and then split up that into generator-canjs like it was before for old canjs?

https://www.npmjs.com/package/generator-canjs
https://github.com/retro/generator-canjs

👍 i am strongly for splitting that so we can start versions in generator-canjs that are related to the canjs parts
and do even more fast release cycles generator-donejs will simply use sub generator-canjs for creating the canjs parts

👎 if we don't take this to canjs directly I will replace it with DoneJS

@matthewp I think your balance point would be solved we defer all DoneJS and canjs parts 👍
so DoneJS add SSR is a valid use case for me as I will never use this SSR implementation it made my head explode without performance gains :) I simply cache or generate static what needs to get hit more often.

@phillipskevin I don't see that point because we could simply do development HTML and point to http-server as server package or even steal-server later. so a user could see Hello World via running http-server in the directory. And if you care about live reload that is solved independently there are really a lot of ways to do that.

For example, i am using in my xamarin clone dev IDE a Live Preview Component that shows me the currently edited HTML already

[phillipskevin]

@frank-dspeed I'm not sure exactly what you're proposing related to generator-canjs. Can you create a separate issue to discuss that?

Since SSR and Hot Module swapping are key features of DoneJS, we wouldn't want to remove them from the generators or guides.

Obviously there are lots of ways of doing everything. DoneJS is our opinionated way of doing them.

[frank-dspeed]

@phillipskevin when the generator-donejs gets splitted and ssr would be optional we still could ask on donejs add app if he wan'ts to use ssr or not and if yes simply npm install that also