Thanks for opening it @juanma 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.
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
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.
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).
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.
It would be very useful for Community Support purposes having this enabled in most Frontity projects. As the frontity commands are mostly executed via npx any change we do there will become the default way for every user from release time
So, while we define a proper way of letting the user choose from different options (and apply different custom configurations from there) I think we can start by adding this sandbox.config.json by default, while we continue the research of custom configurations from CLI questions
My opinion right now is that we shouldn’t add any extra configuration files by default without clearly asking the users if they want them or not. I can imagine a lot of use cases where CodeSandbox won’t be needed (if you are working on a private project for example) and it would feel weird to have that file there.
In terms of user experience, if Frontity users want to convert their project into a CodeSandbox they just have to add the sandbox.config.js file, which I feel is not a big deal. In the future we could even make it easier with a command.
In terms of Community Support, I agree it would help. If I understood it correctly, right now you have to fork the repo and add the sandbox.config.js file yourselves. That way you are able to run the CodeSandbox right?
I’ve seen that, according to this issue, it isn’t currently possible to add the sandbox.config.js file directly in the CodeSandbox after importing the GitHub repo, and that is the reason you have to fork it beforehand. It seems it will be possible in the future and, if users don’t add it in their GitHub repo, we will be able to add it afterwards in CodeSandbox.
To sum up:
If the repo has the proper sandbox.config.js file you can directly import the GitHub repo to CodeSandbox it will work by default.
If the repo doesn’t have it, right now you have to fork the repo, add the sandbox.config.js file yourselves, and you are able to import the GitHub repo to CodeSandbox.
If this issue is solved, if the repo doesn’t have the sandbox.config.js file, you can import it directly to CodeSandbox and add the file there.
Could you confirm if this is right or there is something that I’m missing?
Regarding this, I feel the same way. It’s true we recommend Vercel but I wouldn’t add the file without asking because a lot of users will want to deploy Frontity in other services.
There is another possibility here that may be even better: add support for Frontity in CodeSandbox.
The sandbox.config.json file is a fallback in case CodeSandbox itself is not able to detect the type of project. It is explained here in the “Setting inference” section: https://codesandbox.io/docs/importing#import-from-github
That’s right. Here there are some examples of Frontity projects in Github that doesn’t have a sandbox.config.json and that now can be directly opened in CodeSanbox with the proper links
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 
