Vulcan Cli General Improvements

[Neobii]

Howdy,

I have a couple of suggestions for the cli:

• vulcan create <appName> style=<bootstrap|material> pr
• vulcan heroku, set up heroku / deploy to heroku
• vulcan one2Many, hasOne resolvers on schema fields, creates basic fragments
• vulcan many-to-many <denormalized> (denormalized)hasMany, resolvers on schema fields, creates basic fragments
• vulcan many-to-many <normalized> creates relationship collection, hasMany, resolvers on schema fields, creates basic fragments
• vulcan package update, right now one of the biggest headaches I see with Vulcan is managing dependencies. We should manage the base dependencies in these starter repos and keep them synced.
• vulcan core newVersion “1.14.2” go through vulcan core and upgrade vulcan package versions
• vulcan set-vulcan (one|two) this will set either workflow branch for devel (two repo install) or master (one repo install)

The vulcan cli is fast, but I'm finding that creating my n2n relations takes a bit of time. The relationship properties of schemas are documented, but there isn't much hinting about overall design patterns because they tend to change at this point in Vulcan development... this would be a good way to document the 🌋 way of getting things done.

[eric-burel]

The style argument is indeed a good idea, as well has Heroku deploy.

However I've never managed to do a git based deploy with a 2 repo install so if you have input on this that would be great. There is an old open PR in the docs.

Regarding vulcan package update, the problem is that we never found a automated way of merging an existing package.json with the latest Vulcan package.json, otherwise we would have done smth similar for the starter already.
There has been tests with an existing package (you may find it in the issues) but they did not support most versionning syntax (eg having a beta, removing the tilde to lock the version etc.) so it was a fail.

Can't the resolvers things be added as VS code snippets instead, in Apollinaire's plugin? That may be more efficient for generating schema fields, as intuitively you add relations when you build the schema. However it's not automated so it depends on your use case.
Note that the incoming switch to TypeScript will improve IntelliSense drastically and reduce those issue a bit.

Regarding vulcan core newVersion, I don't really get what you meant?

[Neobii]

Yeah, I was probably going to sed/awk the package versions.

The vulcan core new-version 1.14.2 is a tool for ya'll.

Let's say we need to upgrade vulcan packages to 1.14.2 from 1.14.1 to new release a new version of the vulcan packages to atmosphere. It seems like ya'll have to switch a bunch of 1's to 2's... that's what vulcan core new-version is for.

[Neobii]

Here's an example script for the updating of the vulcan scripts. Must be executed at project root
This script upgrades from 1.14.1 to 1.14.2

sed -i 's/1[.]14[.]1/1.14.2/g' .meteor/versions
find ./packages -name package.js -print0 | xargs -0 sed -i "s/1[.]14[.]1/1.14.2/g"
find ./packages -name config.js -print0 | xargs -0 sed -i "s/1[.]14[.]1/1.14.2/g"

[eric-burel]

You probably need to add "vulcan-*" to your regex otherwise you may also match other packages instead of just Vulcan, however that's a good idea indeed

[Neobii]

The question is, do you want to make it apart of the cli?

[Neobii]

If so, I can flesh out the regular expressions a lil bit and get it ready for the cli... it would be good for me to see how you would add argument handling in yeoman. I got a lil lost with the arguments any quick hints would be cool.

[Neobii]

By the way, when considering making it apart of the cli: I'm studying the way ya'll work and want to build some more infrastructure to help ya'll, so releasing new versions of Vulcan is easier so ya'll can focus on writing code.

[eric-burel]

Many of those issues are Meteor wide btw, you could talk about it on the Meteor forums also. We have way less problems with NPM based solutions for instance, especially with Yarn, because versionning, build and testing works rationally (most of the time), which is not really the case with Meteor.

You still need to improve the regex whether in the CLI or not as far as I understand? The issue is that currently your script may update other packages than Vulcan if by lack of chance it has the same version number.
It can stay in the CLI as we could use it in the Vulcan deployment process too.

[Neobii]

Cool, I'll take care of the regex and have another shot about the convoluted argument passing that exists in the cli.

Instead of style=<bootstrap|material> can it be starter=<starter|bootstrap|material>?

If we come to a point where that needs to be abstracted, we can make a style argument and abstract the style stuff there if need be.

starter= makes more sense on how I'm building the Material-UI starter by including things like a sticky footer layout with it.

[eric-burel]

That could end up being confusing with the Next Starter and the Meteor Starter, we already use the name starter for this. Maybe "ui" is more generic?

[Neobii]

Hmm, if we indeed go to next, then I would remake the Material UI starter to reflect using next. That's one part I would not like to get fragmented.

[Neobii]

or maybe boilerplate is a better word?

[eric-burel]

It's more a starter, boilerplate have a notion of not really being updateable contrary to "starter kits". But that's vague anyway, I say that because we currently alreay call the Vulcan starter "starter".

I am not sure yet how multiple UI system will work in Next. The difference is that Next already includes a default styling option (styled-jsx), so we can expect it to be simpler.

[Neobii]

The thing about the starter though, is that it is more of a learning starter, than a project starter. vulcan has a blank space as far as project starters. That's where I hope to fill the gap with this cli.

btw These cli enhancements are targeted for developers who have got 1 or 2 small Vulcan apps under their belt and used to the speed of Vulcan development once you actually get your dang project set up.

I'm worried about the granularity assumptions of using style at this point.