TiddlyWiki / TiddlyWiki/MultiWikiServer
[v0.1] Working on features for MWS 0.1.0
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 60
- Forks
- 16
- PR merge metrics
- No merged PRs in 30d
Description
Due to significant changes in the database, config, and cli, this will be a breaking change. It would be theoretically possible to have an upgrade path, but it's a nightmare compared to just downloading via the browser and then setting up a new project.
Changes in 0.1.0
✔️ switch all relevant ids to UUIDv7
- recipe, bag, tiddler (aka revision), user, role. the only id that doesn't matter is probably ACL.
- primarily useful for sharding, but user and role ids also have to be strings because most third-party auth libraries use strings.
✔️ rename tiddler_id to revision_id
- along with the UUID change, I'm renaming the tiddler_id to revision_id because it's actually being used strictly as a revision ID, so the name makes better semantic sense. It will also help us avoid gymnastics if we ever introduce server-side revision history.
- a simple global search and replace in the relevant folders does the trick
✔️ remove the current "plugin bag" situation
- client plugins need to be loaded from the tiddlywiki version on startup.
- server plugins may provide additional client plugins which would be loaded the same way.
- some of this is already implemented in 0.0 behind the config option
enablePluginCache, but the current "plugin bag" situation has too many loose ends so removing it is a breaking change. - https://github.com/TiddlyWiki/MultiWikiServer/issues/31
✔️ refuse to upgrade v0.0 databases
- The database init code will detect if the database is a 0.0 database and refuse to upgrade it. Instructions will be given to downgrade and save any information via the browser.
- check if there's a way to do this with an npm preinstall script. If an install script throws, NPM should roll back the changes that were being attempted. Otherwise we'll have to instruct the user to downgrade so they have the proper code to run the old database with.
- Also put these warnings in the readme and update instructions.
✔️ Rework of the commands
- One command per invocation. Since the entire server is compiled into one JavaScript file, it starts very fast.
- The listen command can have multiple listeners as well as any other related options
- All commands operate on the current folder. If the current folder is not a proper data folder, it will exit. An init command will be added to setup new data folders.
- A proper help message for commands will be generated.
✔️ Planned changes to the folder structure and config options
- most of the configuration is going to be in the database
- "wiki path" will be the current directory.
- listen options will be on the cli
- password master key will be in the project folder rather than explicitly specified.
- database connection info will be in the store folder
- https://talk.tiddlywiki.org/t/mws-how-simple-can-we-make-the-cli-for-mws/12460
Server plugins
Premature extensibility is interfering with development.
There will eventually be server plugins, but they will be a completely separate ecosystem from client plugins. Unlike Node TiddlyWiki, there is no overlap between the server and client, so server plugins are completely meaningless to the client, and vice versa. Server plugins may still provide client plugins in various configurations.
The first plugins are going to be in-house plugins that are used to handle things like auth, files, etc. Extensibility is really important to me, but as you may have noticed I've already started running into the "premature optimization" problem.
It's a lot easier for me to extract a specific feature out into a separate codebase and add all the glue layers I need to hold them together than it is to try to work around existing plugin points scattered haphazardly about when I don't even know what the features need to do.
So server plugins aren't going to happen right away, but they're absolutely being planned.
Temporary changes to facilitate development
- Guest access will be removed for now.
- ACL is default deny, so if no ACL is set, no one except admins can access it.
- Removal of config means several previously available options are not available at the moment. Several new options are not yet accessible except through environment variables.
- Removing attachment code which was disabled anyway. It will be re-implemented.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No specific files or tests are named. Start by reading the database initialization and command entry points, then review the README and update instructions; this issue is done only when the selected 0.1.0 changes are implemented and the breaking-change guidance is complete.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend, cli, database
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100