Add CodeSandbox config by default when creating Frontity projects with `npx frontity create`

🗣 Feature Discussions
#1

Description

Just by adding a sandbox.config.json file with the following content

{
  "template": "node"
}

to the structure generated by npx frontity create we would be able to directly open in CodeSandbox all the Frontity projects in a repo by using

githubbox.com/<%GITHUB_ACCOUNT%>/<%FRONTITY_PROJECT_REPOSITORY%>

This would be super helpful for providing support in the Community Forum for specific projects in repositories (like this one → Mobile Error // Unhandled Promise Rejection - can't read the WP REST API)

Examples

This doesn’t work properly in CodeSandbox (doesn’t have sandbox.config.json)

But this one does (does have sandbox.config.json)

Possible solution

Adding this file with this content in all projects created via npx frontity create

Random 404 on Custom Post Types
#2

Thanks for opening it @juanma :slightly_smiling_face: I liked the idea of making every Frontity repository a codesandbox template. I have no idea if it makes sense in terms of the framework itself to have a new file sandbox.config.json. I’m aware that Luis asked if they plan to add support for this configuration in the package.json file, but the issue seems stuck. I don’t know if it would be better to push that issue and add the configuration to the package.json or create the sandbox.config.json.

#3

It would be great managing codesandbox through package.json but that’s something that is not in our hands and that it may take a while.

From my point of view, adding this file in the default configuration is something that can have a positive impact in the way users (and ourselvers when giving support) can access Frontity projects in repositories

I don’t see any drawback on adding this file now, and then managing the configuration via package.json when it works that way. Also I think the effort of implementing this feature is low and the benefits of having this feature are high.

Maybe I’m lacking info here, but that’s my point of view with the info I have.

At the end, you have all the info to properly decide what’s the real effort of doing this and what the priorities are :blush:

1 Like
#4

Yes, I totally agree with this, and as you say we could go with this and change to the package.json if that issue is solved. What I wanted to say is that I don’t have the knowledge to know how “easy” it is to create this new file or if there is something we aren’t aware of. I’m sure @David will know better than me.

#7

Sorry for the late response!

Yes, it would be really easy to do, just adding another step in the create command to add that file.

#9

I’ve been thinking about this and, after hearing the feedback from the dev team, I am not sure it’s a good idea to create a codesandbox file by default after running npx frontity create . I feel it should be optional.

From the perspective of a Frontity user, I imagine there will be a lot of them that won’t be interested in having that file, and it feels strange that they have to delete it if they don’t want it. There are other configuration files that could be interesting for some users, but I don’t feel it’s good to add them by default.

I was thinking that, in order to make it optional, we could include it as part of a list of possible configurations like TypeScript, Prettier or Eslint, where users can select any of them. I’m referring to this Feature Discussion (I still have to divide it in more FDs).

What do you think guys?

#10

I agree it would be better having a CLI prepared for selecting different choices including this codesandbox one, but even with that I would add this file as default (the CLI could ask about codesandbox having the YES option enabled by default)

I think this would simplify a lot providing support in Frontity projects for everyone in the community.

I would say the same for the rest of the options we recommend having enabled for Frontity projects.

#11

This is another thing I would add by default in Frontity projects (even with the CLI filter)

#12

I agree with you:

  • It would be great to have a list, so people don’t get stuff they don’t want.
  • It would be great to mark some of the items by default, so if people is not sure, they can leave it as it is.

I guess we could do it with our current CLI tool: https://github.com/SBoudrias/Inquirer.js#checkbox---type-checkbox

And we can add more items to the list as we go:

  • CodeSandbox template.
  • Git.
  • Prettier.
  • Eslint.
  • Vercel configuration.
  • …