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.
Generate a frontity.settings.js file. (frontity.settinigs.ts if --typescript options is passed)
Create a packages/ directory and clone @frontity/mars-theme inside it.
Install dependencies.
On error: Revert progress.
Create package
Command
frontity create-package [options] [name]
User stories
- As a developer, I want to generate an environment ready to start developing my package.
- As a developer, I want to generate an environment ready to use with TypeScript.
- As a developer, I want to generate a new package in an existent Frontity app.
Result
I’m guessing that the directory structure for packages would be the same as with apps, but I’m not sure. In this case, the important code is inside the package folder, and it should be a git repo. Maybe we should avoid to create a git repo on the root directory.
A scenario that crosses my mind is when we are developing a package, we save the code of that package on Github, but we had some custom config in the root directory to help with development, and that config won’t be saved in Github. To restore that setup with just a command would be desirable but not possible. How can we approach this?
And finally with no args, using a library of questions like inquirer.
> frontity create
- What is the name of the folder?
/my-app
- Do you want to use typescript? [Y/n]
The cli obviously uses the programmatic code underneath.
1 Like
orballo5
I hadn’t think of the programmatic way. I’ll add it to the post.
luisherranz6
I think it’s a good pattern and provides the tool to do the Frontity Admin in the future and makes it “hackable” to others. The “cli with args” option is also good for things like travis and whatnot.
David7
Yeah, great work, @orballo!
Regarding on how to create apps or packages, I think it’s best to use two different commands, even if you haven’t created an app first you won’t be able to use frontity create-package.
I mean, it makes sense to create an app and be able to add one or more packages to that app, develop them in the same project and then, with another command, publish them separately in npm.
I didn’t see it that way. Maybe we could support both ways. What worries me here, is how the repos are going to be used.
If I have an app, I’d like to have a repo with everything, not just my custom package. But maybe I’d like to also have a repo for my custom package (e.g. my theme).
If what I’m doing is to develop a package for the community, I don’t care about the app repo, I’d only want to save the package and that’s gonna be my repo. But, there are some configs in the app that I use for development that would be worth saving, and I’d be loosing them. I don’t know how to make all of this to work together.
I thought about a file called frontity.development.js inside my package, or something like that, to store the settings I need in the app to develop my package, and them another user could just frontity clone-package git@github.com:my/package and generate the whole environment ready to run frontity dev and start coding.
I actually don’t know if all this trouble is really necessary or I’m just overthinking it
PS: Two commands wins!
orballo9
Would it make sense to add an option called --now that would generate also a now.json file?
luisherranz10
now is going to be only one of the possible ways to deploy Frontity so I wouldn’t add anything specific to the cli.
My take on this is: the dev creates the theme/extension inside a “Frontity project”, not in a separate project.
my-custom-theme-project/
|__ .git/
|__ node_modules/
|__ packages/
|__ my-custom-theme/ # <- the dev wants to publish only this
|__ package.json
|__ src/
|__ package.json
|__ frontity.settings.js
When the theme/extension is ready to be published, the dev simply uses frontity publish my-custom-theme and the cli does the magic. The themes/extensions already need a package.json file: they are ready to be published in npm.
The frontity publish command only checks things like if the keywords are right (as suggested by @David a while ago).
Regarding git, the devs can choose if they want to keep a “Frontity project git” (which I think it should be our recommendation), create a git submodule or only use git inside my-custom-theme:
frontity create could fail gracefully if the dev is not in a Frontity project folder and suggest to use create-app instead.
I don’t quite like clone much because it may be confusing (we won’t add the .git folder).
orballo11
Ok, I’ll be updating the first post with any changes I come up with during development and the ideas you are posting here.
orballo12
@luisherranz once we have dev, build and serve in frontity, do we still need those commands to run in @frontity/core? I mean as scripts in its package.json.
luisherranz13
No, we can use frontity dev and so on everywhere.
luisherranz14
It’d be interesting to think about the settings of wp-source:
Give the user the default settings populated, like { api: "https://test.frontity.io/wp-json/" }.
Ask the user about those settings in the create.
And any other setting that needs to be set so the app works.
I really like the final frontity create! I think it’s really good, maybe we don’t need to invest more time now on it right now and we should focus on other important stuff.
orballo19
Yup. After the beta we can try pastel and ink, and also implement the create-package function.
luisherranz20
If we transpile the typescript code to javascript, it cannot access the frontity.settings.ts file.
So either we:
Don’t transpile the frontity code and run it using ts-node.
Transpile frontity.settings.ts with tsc before Frontity starts.