Scaffold CLI tool for creating new projects

[arboleya]

Fuels CLI integration requires fuels.config.ts file generation — #1291

Create a scaffolding tool for generating ready-to-go Fullstack Fuel dApps.

It should support templates and provide a single-command frictionless entry point for newcomers.

npx create fuels@latest my-fuel-dapp
npx create fuels@latest my-fuel-dapp -t <template-name>

Companion frameworks example:

npx create fuels@latest my-fuel-dapp -t next
npx create fuels@latest my-fuel-dapp -t nuxt
npx create fuels@latest my-fuel-dapp -t sveltekit
npx create fuels@latest my-fuel-dapp -t astro
npx create fuels@latest my-fuel-dapp -t qwik

Dead-simple instant quickstart:

npx create fuels@latest my-fuel-quickstart

End goal:

• Single-command, no-brainer, frictionless entry point for Fullstack dApp engineers
• Get users prototyping Fuel dApps in seconds
• Fast development cycle

[Dhaiwat10]

Can I take up this one? @arboleya :)

[arboleya]

Sure!

I'd say let's try to have a first minimal draft template structure considering the quickstart/counter that we can brainstorm over, review, and expand from there. Also, most "companion" frameworks I mentioned in the issue description have excellent interactive scaffolding tools from which we can look and draw inspiration — if we need interactivity, meaning that a first version with only CLI flags like -t, --template may work just fine.

The output of this task should also align with #1291/fuels.config.ts, so you'll need to use that branch as the base branch for moving in parallel. Remember that the former PR is fresh and subject to changes, so it's wise to be flexible and keep some open ends to avoid over-refactoring as we approach the end.

[Dhaiwat10]

@arboleya @FuelLabs/sdk-ts I have created the first draft for the template here if you want to have a look: https://github.com/Dhaiwat10/fuel-cli-starter-template

[luizstacio]

How are we thinking about template resolution?

I think using something like create-react-app that uses npm or using GitHub would be good, in this way:

Resolving templates:

• npm: --template xyz, the resolver would look for an npm module with the name create-fuel-app-xyz or cfa-xyz. Install and use the template.
• GitHub / Git: --template @user/xyz or full path --template https://github.com/user/xyz.git we would use git to clone and install the template.

[arboleya]

@Dhaiwat10 I wonder if keeping the whole contracts directory inside src is the best option—more here.

[arboleya]

@luizstacio What do you think about a hybrid approach, like a mix of built-in and community templates? My concern is that having all built-in templates scattered around in different repos could add unwanted maintenance complexity for us.

[Dhaiwat10]

@arboleya I see. I agree about the nomenclature decision you took there. Do you want me to move the directory one level out to the root of the project?

[Dhaiwat10]

Agreed @arboleya, I think we should only have two or three 'official' templates at most - covering the most popular frontend frameworks. This would be sufficient for 99% of our users.

[danielbate]

Can we tie it in with the frameworks in the apps directory, that way we ensure they are kept up to date.

[Dhaiwat10]

@danielbate good idea. Let me see if I can pull that together.

[Dhaiwat10]

btw one thing that I found when working on this issue was that npx create fuels won't work. That syntax only works with pnpm. Let's take the example of create-next-app.

As you can see in the package.json, the package's name is create-next-app. This means that the syntax for it would work like this:

npm - npx create-next-app
pnpm - pnpm create next-app

create has to be a part of the name of the package. npx create next-app doesn't work.

For our tool, I think we should just add another command called create so it works like this:

npx fuels create and pnpm fuels create

Thoughts?

cc @arboleya

[arboleya]

Just leaving a ref. of what we spoke here.

I believe all these may work:

• npx create-next-app
• npm create next-app
• pnpm create next-app

[luizstacio]

I think it is the other way around, but by allowing the community to build the templates, we can reduce our management coverage. We just need to ensure on the install to use the lock inside the template etc...

Also, we incentivise people to build templates for other languages otherwise is going to be in our hands only to create these templates.

[Dhaiwat10]

I propose we create a repo similar to this one by Next.js where we can store our templates. To start with, we can add two or three 'official' templates. The community can then keep adding templates to this repo via PRs.

[arboleya]

That makes sense.

Should we also move our demos to this repo? It could remove a lot of the bloat.

• demo-nextjs
• demo-nodejs-esm
• demo-react-cra
• demo-react-vite

My only concern is that these demos are currently used to validate that the SDK compiles correctly using each tool. If we move them outside, it'd be great to keep these validations. Perhaps some CI automation could do it.

Have you thought about it?

[Dhaiwat10]

@arboleya
Definitely doable. I think the demos would also become redundant. The templates and demos both serve the same purpose. The only difference is that the templates will also include integrations with the fuels CLI and maybe the wallet SDK.

Maybe it would be a good idea to tackle this transition separately after this PR?

[arboleya]

Yes, it might be better to do it in separate PRs.

[arboleya]

@digorithm Is there any procedure we need to follow for creating new repos?