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 
