Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IDEA] Template based generation tool in cli #8548

Open
linonetwo opened this issue Aug 23, 2024 · 6 comments
Open

[IDEA] Template based generation tool in cli #8548

linonetwo opened this issue Aug 23, 2024 · 6 comments

Comments

@linonetwo
Copy link
Contributor

linonetwo commented Aug 23, 2024

Is your feature request related to a problem? Please describe.

https://tiddly-gittly.github.io/Modern.TiddlyDev/ provides a cli tool to bootstrap a project boilerplate.

After seeing https://talk.tiddlywiki.org/t/10475 I think there can also be tiddlers-level template.

Describe the solution you'd like

For example, I shouldn't add doc like #8472 , but instead I create a tiddler with tag $:/tags/GenerationTemplate, and necessary metadata.

If we are not going to add them to the official doc wiki, it can also be added to a new edition.

And tiddlywiki npm package can prepack / download / request the wiki, list & search the template user wants, and apply it to a folder, when developing plugin in nodejs wiki.

Describe alternatives you've considered

There is already a plugin https://github.com/tiddly-gittly/template-list that can read template tiddler from plugins, and apply them. But it only support single tiddler currently, while sometimes a feature will need multiple tiddlers to work.

Additional context

There is Notion template market, and many Obsidian users share their vault via github. But we can do more than that in TiddlyWiki. I've heard there will be a template market after MWS is finished, so maybe this can be implemented after that.

@linonetwo linonetwo changed the title [IDEA] Template tool in cli [IDEA] Template based generation tool in cli Aug 23, 2024
@Jermolene
Copy link
Member

Hi @linonetwo this sounds intriguing. I understand part of the idea is to provide tiddlywiki commands for creating tiddlers according to a template. Would you imagine that being a file system operation, or would it create the tiddler via the usual API and rely on the sync process to write it to disc?

@linonetwo
Copy link
Contributor Author

I usually have my own folder structure, and I will want templates to be generated in the location I want, so it might works like $:/core/modules/commands/render.js, user provide a path, and this command directly write several tiddlers to the provided path, or CWD.

And it might fetch tiddlers from the internet (tiddlyhost or github pages). People can share a shell command like tiddlywiki --template NewCascade ./src/plugin-name/ui/view/ https://tiddlywiki.com/dev/.
So we don't need to bring every templates with tiddlywiki npm package. This is different to --render command.

@Jermolene
Copy link
Member

Hi @linonetwo OK that makes sense. Maybe this is the time that we should start using npm scoped packages, publishing these tools as tiddlywiki@devtools (or something). Then if I understand correctly users can use npx to run these additional tools without needing to install them first.

@pmario
Copy link
Member

pmario commented Sep 8, 2024

I would like to raise my concerns.

We already do have the --fetch command that can load content from the web. So IMO we do not need a second one, that potentially can accidentally load untrusted code from the web.

We do have --fetch, --init, --import, --load, --save, --savetiddler, --savetiddlers and unpackplugin that do very similar things as discussed in the OP. None of them is well enough documented, to be usable by new users. They are even hard to use for experienced users. Some of them are deprecated.

I doubt that tiddlywiki --verbose --fetch file "https://tiddlywiki.com/" "[!is[system]]" "" --rendertiddler "$:/core/templates/exporters/JsonFile" output.json text/plain "" exportFilter "[!is[system]]" makes much sense for someone else than Jeremy.

So adding a new command that mixes functionality from the afore mentioned ones IMO is not the right thing to do.

We should have a look, if a combination from --fetch, --import and --init can create what we need. On the way there, we could improve the documentation in a way, that makes the existing commands more accessible for everyone.

@linonetwo
Copy link
Contributor Author

linonetwo commented Sep 9, 2024

@pmario I didn't know that. --fetch looks good, with a modification to --rendertiddler, it will achieve what I describe above. Only need to let --rendertiddler output multiple .tid file. Even output a folder structure, based on metadata on tiddler with tag $:/tags/GenerationTemplate. (oh, I haven't design the metadata yet)

If the complete command is too long, we can provide a button to generate it and copy to clipboard. I imagine when people provide template on their own blog wiki (or a private wiki on tiddlyhost that password is bought on Patron), they will also provide this button.

So there don't need to be another npm package. (While we could still move https://github.com/tiddly-gittly/Modern.TiddlyDev from tiddlywiki-plugin-dev to @tiddlywiki/plugin-dev).

@Jermolene
Copy link
Member

@pmario I didn't know that. --fetch looks good, with a modification to --rendertiddler, it will achieve what I describe above. Only need to let --rendertiddler output multiple .tid file. Even output a folder structure, based on metadata on tiddler with tag $:/tags/GenerationTemplate. (oh, I haven't design the metadata yet)

If the complete command is too long, we can provide a button to generate it and copy to clipboard. I imagine when people provide template on their own blog wiki (or a private wiki on tiddlyhost that password is bought on Patron), they will also provide this button.

We could also look at extending the current --build mechanism:

  • Make it possible for build commands to use parameters so that we can do things like --build core-template-cascade MyNewCascade. Perhaps the implementation would work by allowing build commands steps to be specified as a filter instead of a raw string
  • Perhaps allow build scripts to be retrieved dynamically when the name starts with https://, or a special symbol like @

The name --build would become a bit of a misnomer, and we might consider providing a generic alias like --run, and call these things "command scripts".

So there don't need to be another npm package. (While we could still move https://github.com/tiddly-gittly/Modern.TiddlyDev from tiddlywiki-plugin-dev to @tiddlywiki/plugin-dev).

We should start a separate discussion about this, I think it would be an excellent idea. We should take the opportunity to automate the main npm build as well (I currently run the build on my machine).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants