(Note: a previous version of this blog post introduced Ignite Flame as version 4.0. Since then, we have decided to publish as 6.0 to avoid confusion with Ignite Bowser 4.x and 5.x.)

5-minute Video Intro

Ignite is well-known in the React Native world. It’s a collection of all of Infinite Red’s opinions on stack, patterns, and packages in one place. It usually saves teams about two to four weeks off the front end of their React Native projects.

Almost three years ago,

unveiled Ignite 2.0, which brought in the concepts of “plugins” and third-party boilerplates to Ignite.

The reasoning was sound: not every project is the same, and we wanted to have the flexibility to support many different needs and opinions on our wildly popular Ignite CLI.

But over the following years, we learned that maintaining an ecosystem of plugins and boilerplates — especially as a relatively small team — was easier said than done. Not only that, but with a few notable exceptions, Ignite continued to be what it always was: Infinite Red’s battle-tested stack & patterns in a single boilerplate.

And yet, there were all these other pieces that had to be maintained: two official boilerplates, CLI, plugins, generators, “sporking” (don’t ask), and much more. Plugins, while a cool concept, were challenging to keep up to date as well, and a source of a lot of issues.

Flame

After several conversations about this, we decided to take a step back in time and re-combine Ignite into a single code base. But this time, we’d have the full power of Gluegun at our fingertips and all the learnings from the last five years of React Native. We called this effort “Ignite Flame”.

🔥 Plugins are gone!
🔥 Third-party boilerplates are gone!
🔥 “Sporking” is gone! (more on this later)

We’ve reduced the complexity of the code base by a lot. The Ignite 2.0 CLI was over 3,000 lines of code in 57 files. The Ignite Flame CLI is under 1,000 lines of code in 15 files. It also takes about 25% less time to spin up a new app from scratch.

Note that Ignite 4.0 and 5.0 don’t exist — we are skipping those versions to not cause confusion for developers who have used Ignite Bowser 4.x and 5.x in the past. Ignite 6.0 is the new Ignite!

Boilerplate

Our philosophy is that nothing makes it into our boilerplate until we’ve proven it in a real-world client project at Infinite Red.

Our first version became the legendary Ignite Andross, and we then switched over to the top tier Ignite Bowser which is still our standard today.

Ignite Flame continues that tradition, bringing in Bowser to the main repo and allowing for a tighter integration between the Ignite CLI and our favorite boilerplate.

We’ll no longer call it Ignite Bowser — it’ll be simply “Ignite”. Just like the 1.x days. Any new versions will be released as 6.x, 7.x, etc.

Our battle-tested stack, as of Ignite 6.0, will be the following:

• React Native 0.63 — latest RN
• TypeScript 4.x — type checking
• MobX 6 & MobX-State-Tree 4 — state management
• React Navigation 5.x — navigation/routing
• Detox 17.x — end-to-end tests
• apisauce 2.x — network requests
• expo-localization — internationalization
• reactotron — debugging and inspecting state

We also support Expo out of the box, and new to Ignite 6.0 is Expo Unimodules support even when you don’t select the managed Expo option!

If you want to know more about why we chose the stack we have, head on over to the documentation.

Generators

While plugins and third-party boilerplates were rarely used, generators were the “hidden gem of Ignite”.

What’s a generator? It’s a command that you can run from your terminal to create boilerplate components, data models, and the like. It makes it super simple to add components or other files without having to copy & paste.

The previous version of generators wasn’t very flexible. If you wanted to customize your generator, you’d have to run ignite spork (which was an odd naming choice). Most Ignite users weren’t even aware this was an option.

The new generators are much more flexible and simple to use. When you spin up a new app, you get a folder:

ignite
  |- templates
     |- component
        |- NAME.tsx.ejs
... etc

If you look at the NAME.tsx.ejs file, you’ll see that it’s an ejs template.

// ... omitted some for brevity
export const <%= props.pascalCaseName %> = observer(function <%= props.pascalCaseName %>(props: <%= props.pascalCaseName %>Props) {
  const { style } = propsreturn (
    <View style={[CONTAINER, style]}>
      <Text style={TEXT}>Hello</Text>
    </View>
  )
})

When you run ignite generate component HelloWorld, this file will be copied into the appropriate folder (app/components/hello-world ) and parsed using the ejs template system. Any props will be passed in, such as <%= props.pascalCaseName %>, and replaced with the appropriate names. For example, the command above would generate the component like this:

// ... omitted some for brevity
export const HelloWorld = observer(function HelloWorld(props: HelloWorldProps) {
  const { style } = props
return (
    <View style={[CONTAINER, style]}>
      <Text style={TEXT}>Hello</Text>
    </View>
  )
})

If you want to customize those generators, just edit the template files in ignite/templates, and anytime you use the generators, they will have your customizations.

If you want to reset them back to defaults, or you’d like to update the template to a newer version, just run ignite generate component --update and they’ll be updated to the latest version.

Upgrading From Previous Versions

You can find a diff (thank you

!) between previous versions of Bowsers and the new Ignite Flame, as well as future diffs, in this repo:

For Expo apps, there’s a different diff repo:

Older Bowser-specific diffs here:

Going Forward

Ignite will be much easier to maintain going forward, and so we expect a lot of improvements to be headed your way.

If you’re interested in helping out with Ignite, join the Infinite Red Community Slack and reach out in #ignite (tag

in there). And follow @ir_ignite on Twitter!

Thanks to

and for helping me with this rewrite!

Happy Igniting!