mojito-cli creates wrong mojit-template concerning to controller.server.js

[ItsAsbreuk]

inside controller.server.js ac.models.get() calls the model by modulename.
As from 0.8.0 that is changed into the modelname.

[lzhan]

@ItsAsbreuk Thanks for reporting this issue. A card is added to our todo list.

[lzhan]

@ItsAsbreuk : when Mojito 0.8.0 was released, mojito-cli-create was updated too. You might need to update mojito-cli by "npm install --global mojito-cli". Please let me know if you still see the same issue after that.

[ItsAsbreuk]

@lzhan just updated mojito-cli and indeed that solved the problem.

Strange, if I remembered right, i did update the mojito-cli when i updated mojito to version 8. I must have been wrong...

The problem is solved then.
I'll close the ticket.

Thanks,
Marco.

[lzhan]

@ItsAsbreuk No problem. Thanks.

[caridy]

this is why I fought very hard to get the archetypes in mojito pkg rather than the global cli :/

[ItsAsbreuk]

well, I'm not a principal developer, but here are my pennies:

1. I sounds logical mojito-cli's version is bound to mojito's version. I should have upgraded -i thought i had- but it makes more sence when mojito-cli follows the same major-release-nr as mojito. Thus: mojito-cli version 0.8.x

2. It sounds reasonable that the archetypes are within mojito-cli because you don't have duplicated archetypes in all projects. However, i am running multiple mojito-projects on my server. They are not all mojito-version 0.8.x. This makes mojio-cli quite unusable for my previous mojito-projects. So, what about having mojito-cli archetypes for all major mojito-releases? So it can get the right archetypes for every specific mojito-project.

3. Because (i think) mojito-cli ought to be updated on every major mojito-release, why not let mojito-cli throw an error when it tries to interact with a higher mojito-version? Just throw an error like: "you need mojito-cli version 0.8.x if you want to perform this action on this mojito-project". It helps if mojito-cli follows the same version-pattern as mojito does.

just the way i see it.

Kind regards,
Marco.

[caridy]

@ItsAsbreuk some of those thoughts make sense, and in fact they are the recommended way to use the cli, but the reality is a little bit different. Imagine an scenario where you have two mojito projects, one using mojito 0.7 (which you can't update for business reasons, which is very common) and another one using the bleeding edge of mojito, then how do you solve the mojito create? are you going to install two cli's? or switch between them? how?

The archetypes are bound to the mojito version installed in your project, and the cli should rely on that pkg, and the content of the pkg to resolve which archetype to install, that way you get updated archetypes with every new version of mojito without having to update a cli.

anyhow, this was slippering, and I don't recall the exact reason why @isao did this, there must be a reason.

[ItsAsbreuk]

@caridy, @isao,

my thoughts were having one mojito-cli (of coarse). and make it sniffing inside the mojito-project for the version it is using. this way mojito create always 'creates' archetypes of the mojito-version it was meant to. And, if the mojito-project resides at a higher level than mojito-cli (which is theoretical possible when cli is downgraded or a 'higher-version' project is copied manually to the server), than mojito-cli throwing an error.

don't know if this is the way to go or posible, but maybe something to think about.

[isao]

@caridy the archetypes needed to be in the cli because mojito create app couldn't assume that mojito was installed, and if it was, wouldn't know where (non-global). It was the "quick start" use case.

I recall proposing a config for the cli commands, which in the create case could be used to locate for archetypes locally, and eventually over http. But there was a lot of resistance to this.

I'll submit a PR in a few to have create use a mojito-lib archetypes dir if known, which should help.

[isao]

@ItsAsbreuk thanks for the feedback and suggestion. pull isao/mojito-cli-create#6 will use a locally installed mojito/archetypes directory to look for matching archetypes which should help with mojito create mojit ... being more in sync. mojito create app.. is a different story of course, but there remains these options:

• specify the full path to the archetype like mojito create path/to/mojito/archetype
• specify the path to a moijto install with the --libmojito path/to/mojito option. If there is an archetypes directory there, the create command will attempt to use it.

[ItsAsbreuk]

@isao ok, great!
thx.