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

🗣 Feature Discussions Closed
#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.
  • …
#13

@SantosGuillamot Any update on this?

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

What do you think?

#15

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.

#17

Yes, I think this is right

Oks, then. Let’s wait until we can add this configuration questions from the CLI.

#18

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

It also points to where the logic is: https://github.com/codesandbox/codesandbox-importers/blob/master/packages/import-utils/src/create-sandbox/templates.ts#L63

If we do a PR to CodeSandbox so it can automatically recognize Frontity projects, the sandobox.config.json file won’t be necessary anymore.

For what I see, I guess it should be as simple as this:

if (totalDependencies.indexOf("@frontity/core") > -1) {
  return "node";
}

This is a similar PR for another framework: https://github.com/codesandbox/codesandbox-importers/pull/84

@juanma, what do you think?

2 Likes
#19

That would be great. I think it’s a great solution :+1:

@luisherranz Can you do the PR? Do you want me to do it?

#20

If you could do it that would be great thanks! :grinning_face_with_smiling_eyes:

#22

PR created! :+1:

1 Like
#24

Ives merged the PR yesterday :tada::tada:

I guess this means no need for the sandbox.config.js file anymore.

#25

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

https://github.com/frontity-demos/demo-custom-homepage-categories

  • https://codesandbox.io/s/github/frontity-demos/demo-custom-homepage-categories/tree/master
  • https://githubbox.com/frontity-demos/demo-custom-homepage-categories/tree/master

https://github.com/frontity-demos/2020-04-mowomo-react-wp

  • https://codesandbox.io/s/github/frontity-demos/2020-04-mowomo-react-wp
  • https://githubbox.com/frontity-demos/2020-04-mowomo-react-wp
1 Like