The team is now working on the WordPress Interactivity API. This unblocks the same UX Frontity framework enabled but directly in WordPress Core, fully compatible with the new Site Editor.
I’ve also been thinking about this, but my idea was to add it in npx frontity build because you may want to clone a project and deploy it in different hostings, or even create a npx frontity deploy command that does the whole process for you. In case of now, for example, it will:
Ask you about your app if you don’t have a now.json yet.
Create the now.json
Call now to do the deploy.
Other builders may do different things. For example, if we have a builder for AWS lambdas, we don’t need to add the lambda wrapper for everyone, we just adde it when people run npx frontity build specific for AWS.
I also thought it’d be nice to make it extensible, so the community can create they own build/deploy tools.
# Build frontity for now.
> npx frontity build @frontity/now
# Build frontity for AWS lambdas.
> npx frontity build @frontity/aws-lambda
# Custom build for a Pantheon, for example.
> npx frontity build @pantheon/frontity
@frontity/now, @frontity/aws-lambda and @pantheon/frontity would be npm packages with the commands to do the build/deploy. Any person could create a package. They could also accept arguments or be used programatically.
Oh, we could implement your picker idea but in the build/deploy with the official frontity packages:
> npx frontity build
Pick a deployment target: (Use arrow keys)
- now
- aws-lambda
- other (specify a builder package)
- none (just a normal build)
juanma4
For deploying with now you don’t need to launch the build step
Just doing now --prod (inside project’s folder) after npx frontity create my-project does the deployment
luisherranz5
Yes but still need to create a now.json file and many other will be better handled with a build step, like AWS, Netlify, Firebase and so on. So it’d better to have a standar way to do things.
juanma6
Maybe having both commands is the way to go, so you can do…