Ignite: The 1st Generator

[GantMan]

RE: #447

OK, I've regressed on generators quite a bit. I was considering the generator for react-native-elements and it seemed kinda complicated, so I figured, let's go in-house! So I was considering maps. But woah... that's a thick one.

After talking with @kevinvangelder - we realized this was starting too high. People want to change our screen generators, and our screen generators should be overridable, and should work the same way as a map generator etc.

Here's the proposed first generator concept workflow: In this example, a user does NOT have screen generators, but does have the latest ignite. (Now obviously some generators, like screens should already be there)

Adding a generator

1. User types ignite add screen-generators
2. Ignite looks for an npm package named ignite-screen-generators and installs it.
3. Ignite then runs the initialize function on that package.
4. The initialize function then adds the supported generators to the .ignite file's available generators section. (Enforcing friendly overwriting is key)
5. Any application changes are then made (adding permissions, npm i, npm link etc)

_The app is then ready._

Using a generator that has been installed.

1. User types ignite generate Screen TacosLocos
2. The generate command checks local generators from .ignite file
3. CLI calls the given generator (this will take some research as generators ALSO have a naming convention, which we will need to assuage).
4. The given generator then runs with all params passed along.

Feedback please, and then I plan on implementing this.

[GantMan]

Current progress of CLI

[x] Adding generator to add, warns if no npm exists.
[x] npm installs the given package (basic-generators looks for ignite-basic-generators)
[x] Ignite then imports the newly installed package correctly
[x] Ignite runs the initialize function on that package
[x] CLI manages interpreting initialize
[x] Warn if we're about to overwrite an existing listed generator

Current progress of Generator

[x] Create a generator named ignite-basic-generators
[x] Make an initialize function
[x] Have the initialize function register its generators with the CLI

Current progress of CLI/Generators command

[x] look up generator in local .ignite function

[juddey]

am I allowed to say 😕 ?

[GantMan]

lol, what's wrong?

[GantMan]

So far my tests are going amazing! I updated the checklist to latest status.

[juddey]

We could also do a generator for react-native-keychain, I reckon that will be a pretty common requirement.

[GantMan]

I have a functioning end to end example! I'm going to try to find some corner cases, but the very first 3rd party generator is done!

[GantMan]

added some friendliness tonight:

[juddey]

🏇

[GantMan]

This branch consumes and uses this generator.

Feedback welcome. Before I do the PR I want to make sure I have as much cleanup/docs ready to roll as possible.

[juddey]

Updated my ignite to this branch and generator. First Look: 👀

• I wasn't clear (from the readme) whether you needed to npm install the ignite-base-generators first before running. I did that, then remembered, 'oh, yeah, this new wonder thing installs the generator too'. So all that's needed is to update the readme to add the base-generators install instruction.

• Should ignite-base-generators be added to devDependencies rather than dependencies?

• I got a bit confused with the package name as against the generator name. In some places, we're installing ignite add basic-generators but when you look at the package on npm its ignite-base-generators and what's installed is ignite-basic-generators... might be worth prefixing 'ignite' in front of the ignite add command too so they're consistent.

• For the future might be worth considering some dup checking so the npm module isn't installed twice.

I'll keep running with the new and beautiful versions and let you know anything else I think of.

[GantMan]

@juddey - great feedback!

• yes the README docs need help. I have a lot of docs to update when this goes live. I'm not looking forward to all the doc updates, heh. But I hope to make the final docs spectacular!
• I agree dev dependencies is key for this plugin, but it might not be for all plugins. I'll default to dev dependency for now.. but I might think of a way this gets in the way. I'm wondering how best to handle this.
• yeah, the package name will need docs. The plan is "ignite-" gets added to whatever you type. That way we don't have to fight for good names. I feel this is a good move. Also, it helps us identify plugins.
• agreed, that's a good speedup option. Though you'd have to ignite add samething twice right?

[juddey]

I agree dev dependencies is key for this plugin, but it might not be for all plugins. I'll default to dev dependency for now.. but I might think of a way this gets in the way. I'm wondering how best to handle this.

Aah! I didn't think about back the other way. I can see why that might be problematic.

I did ignite add twice to see what might happen. Not that it was in the original thinking, just thought I'd see if I could break something 😸

Agreed on prefixing ignite- too.

No usage problems so far though :)

[juddey]

I can also see that the prep work that I did in #66 will still be able to be used 🎉

I'll probably regret this, but let me know if you want me to have a crack at the doc updates too.

[GantMan]

indeed!

I think ideally, I'd have you help spitball with me on #447 to make sure I didn't leave out something in the direction I'm going. I think the base project needs to move the dev screens to the side a little. And there's the need of "examples" when a new plugin is brought in. Something tells me we're still in the rough with this generator biz, but at least it works.

Honestly, if you want to carve off the next generator for yourself (either an existing feature moved to plugin like here, or some fancy library we've yet to include yet) and let's find out what was simple and what needs to be still added.

After we've converted over a few, I agree, all hands for documenting! Maybe even a directory of known plugins at that! I have no doubt there can/will be a multitude of plugins once this is smoothed out.

[juddey]

Cool. Might switch into hack mode for #475 then, and try to bring that on as an example. That way, I won't trip over the work that's being done here. Then look again at #66, unless something else comes up in the meantime 🔮 .

[GantMan]

hrmm yeah. With no .ignite file in place, it should still work. But that's kinda untested.

[juddey]

aah just deleted that comment, I managed to sort it by reverting everything back. I did have an .ignite file in place but as you know mines somewhat dodgy so I wouldn't be trusting it at all.

I'd better start a new project so I can use these new generators then hahahahaha :)

[jsheets]

Just wanted to say, thank you for working on this. I like the templating support, but I end up doing quite a bit of tweaking to every component I create. It'll save me a lot of busy work when I can customize the templates to match my own coding styles.

[GantMan]

Awesome. We're making templating a first class feature for all generators. I'll be sure to update you when you can test.

[GantMan]

after speaking with quite a few people about the aforementioned, we're moving to a more advanced system.

.ignite will be moved to a ignite folder. The ignite folder will contain the .ignite file and any templates that have been pulled out of their node modules with the fork command.

_id est_ - If a user wants to customize the screen generator, they can type ignite fork screen and their template shall move from node modules the the ignite folder where it can be edited. Folder names must match generator names once moved (renaming the folder if necessary).

Logistics

The .ignite file will still point at node_modules version. But whenever a folder of the generator name has been copied to the ignite folder, that generator shall rule supreme.

💯 BONUS: This is how we will test generators locally before they become node packages.

cc: @skellock @brentvatne

[skellock]

My $0.02 (CAD) is that we figure out exactly what an Ignite 2.0 plugin is.

The ability to create plugins per-project is what will have me using this full-on. This is why I've been advocating local templates.

Your fork idea is really neat. I'm just a bit hesitant because a plugin includes submodules and could be a very slippery slope.

Defining what a plugin is first will help you decide what exactly you're forking.

I'm currently in :shipit: mode for a client project, but I can find time if you're interested in chatting more.

[GantMan]

the fork idea technically is Brent's. I can't take credit. But I want that experience, so yes, let's chat.

[skellock]

Just chatted with @GantMan.

Basically cp -R without node_modules and package.json, then instructing the ignite runtime to look there first.

What we ended up talking about was a pseudo fork:

ignite spork SomeoneElsesPluginThatWasAlmostExactlyWhatWeNeeded

It'll be basically an incubation hatchery for future ignite plugins (if you wanna go that route).

Neato mosquito.

[GantMan]

Also, as per steve's request, we will not depend on Yeoman, that will be a choice at the generator level.

[GantMan]

Moved .ignite to Steve’s ./ignite/ignite.json folder and prettyfied it. This is a breaking change for any older generator that used the old .ignite file. Additionally, I’ve created the apply step in the add process. Which helps users deny overwriting generators. This is done in a callback method. I wouldn’t mind cleaning that up into a promise.

[GantMan]

More Ignite Genertaor progress

✅ Add spork command
✅ Use sporked generator

[GantMan]

@juddey - this is completely different now. Will update you soon.

[skellock]

Winter is coming.

[juddey]

You mean summer? I'm sitting here coding in shorts, t-shirt and flip-flops.
🌞 🌏 ⛄️

[skellock]

Never did understand how Aussies hang upside-down their whole lives.

[juddey]

@skellock Gravity. Simple as that.

Also: self.nationality = 🇳🇿 . self.nationality == :australia: { return false }.

[skellock]

Found the ruby programmer!

[juddey]

self.rubyist ? :ok_hand: ➕ 😍 ➕ :tada: : nil

[sourcesoft]

Guys does this functionality helps with keeping local and ignite-repo fetched and merged (like ignite-base folder)?

I've ran ignite new myapp a month ago and after 30 days feel like living under a rock now 😄 . 50+ commits are submitted and I have no idea how to be updated and keep track of changes (from package.json deps to Containers/App, ...).

There should be some way to have more than just awesome generators, maybe I'm missing something here 😕

[GantMan]

This is a step in the right direction. For things to keep updated, things have to be applied or removed properly. Though it is not the goal of ignite 2.0, it is a benefit that somewhat gets applied.

We're open to feedback on how best we can keep repos up to date, but that is slated for Ignite 3.0 on our roadmap.

[skellock]

The original issue has been resolved, but a bunch of other things came up in this ticket.

@sourcesoft has a really good point. Tracking that in #739