Open linonetwo opened 3 weeks ago
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?
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.
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.
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.
@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
).
@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:
--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 stringhttps://
, 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).
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 https://github.com/TiddlyWiki/TiddlyWiki5/pull/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.