Add some new scripts to package.json, to make npm run command easier
add some new scripts to package.json, to make npm run command easier
- relies on: #8265
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Updated (UTC) |
|---|---|---|---|
| tiddlywiki5 | ✅ Ready (Inspect) | Visit Preview | Jun 27, 2024 6:28pm |
The structure changed completely.
- We do have the basic commands:
- start, test
- A wiki command, that is used with
+plugins/tiddlywiki/filesystem +plugins/tiddlywiki/tiddlywebplugin prefixes - A cs command for "client server"
- server and server-external-js, because there "naming pattern" is completely different
pluginlibrary is missing, because we need to handle the PR: Make pluginlibrary edition consistent with all other editions #8265 first
multiwikiserver is missing since it does not have a tiddlywiki.info file.
share has no tiddlers/ directory so it's missing too - I don't know what to do with it
If I clone a new repo, one of the first things I usually do is run npm run to see what's going on.
The command creates this output. Which should be somewhat self explaining.
Since wiki:info is the first thing, we do get some help info, without running any commands. So for most users that will be enough info to get going. If they run npm run wiki they get an error -> which is OK
Everything needed is there now, to be selected with the mouse and "copy / pasted" into the command line.
A similar output is created for npm run cs, which can be used for editions that have a separated *-server edition.
@Jermolene -- what do you think?
Feedback from npm run cs
- A cs command for "client server"
I think that is too obscure. Can we use "server" instead?
- server and server-external-js, because there "naming pattern" is completely different
If we cater for external-js then perhaps we should also cater for lazy loading?
multiwikiserver is missing since it does not have a
tiddlywiki.infofile.
I think you've got a blank folder there because at some point in the past you've checked out the multi-wiki-support branch, and then weirdly when you check out a different branch, git seems not to remove the directory.
share has no tiddlers/ directory so it's missing too - I don't know what to do with it
That edition is just a wrapper around the "share" plugin, and doesn't need any tiddlers.
Just an info: Problems with missing tiddlywiki.info files has been solved with Fix tiddlywiki --editions command #8535
- The
cscommand has been renamed toedition - The
librarycommand starts the local library server at port: 8888,- so it can be tested with a second server at port: 8080
npm run now shows this info
Possible commands are
npm start... starts tw5.com-server --listennpm test... runs all tests
npm run wiki --edition=<wiki name>... this one starts wikis without a server editionnpm run edition --edition=<edition name>... this one starts wikis, that have a*-servereditionnpm run library... builds all plugins and starts the library server on port:8888npm run server-external-js... starts the corresponding editionnpm run help... runsnode ./tiddlywiki.js --help... to get all CLI info
Updated screenshot in last post. Moved help, lint and lint:fix up in the hierarchy
I wrote:
- server and server-external-js, because there "naming pattern" is completely different
Jeremy wrote: If we cater for external-js then perhaps we should also cater for lazy loading?
I do have no idea how lazy loading works and how to set it up. @linonetwo can you make suggestions here?
@linonetwo ... In general, what do you think?
Sure, I use lazy-loading everyday. Simply add a rootTiddler will enable lazy loading
https://github.com/tiddly-gittly/TidGi-Desktop/blob/fe3a29eff1fb7e70307c2f3d29483681d535403d/src/services/wiki/wikiWorker/startNodeJSWiki.ts#L125
Try add
"server:lazy": "node ./tiddlywiki.js ./editions/server root-tiddler=$:/core/save/lazy-all --listen",
or this, so there are existing tiddlers:
"server:lazy": "node ./tiddlywiki.js ./editions/tw5.com-server --listen root-tiddler=$:/core/save/lazy-all",
@Jermolene @linonetwo -- this one should be ready for review now
How about add default script like
"wiki:default": "node ./tiddlywiki.js +plugins/tiddlywiki/filesystem +plugins/tiddlywiki/tiddlyweb ./editions/dev --listen",
so we can click on button to open, instead of use cli. I usually start/restart wiki in this way:
or hover here
only need to click on it.
Anyway, a clickable "start" is enough for me to test my PRs.
IMO for debugging you can use F5 and define as many configs as you need there. npm scripts imo are for the CLI
It occurs to me that the use of npm run and the details of the supported commands should all be documented on tiddlywiki.com.
I can do this, once we are OK with the names and the mechanisms that are outlined here. The minimum info needed is at: https://github.com/TiddlyWiki/TiddlyWiki5/pull/8294#issuecomment-2299770500 atm.
@Jermolene ... I think this doc should be in the dev-edtion. right?
One of my mainstays is an npm run dev script that starts node.js with the --watch-path flag so that any changes to a core file automatically restart the server. Something similar in the bundled scripts would be very welcome.
See https://nodejs.org/api/cli.html#--watch-path
@saqimtiaz ... This will require Node.js 22.x as a minimum version, if I can see that right. Latest LTS is 20.x @Jermolene ... Do we want that
I personally would like to have a native -watch feature
the --watch-path argument was added in node v18.11.10 as an experimental feature and is stable in node v20.x LTS.
@Jermolene ... I think this doc should be in the dev-edtion. right?
I think it makes sense to document them along with the other command line details in tw5.com.
In terms of which Node.js versions that we target, perhaps it would make sense to adopt the policy to target the oldest LTS version of Node.js, which would currently be Node.js 18. That's the version used by our CI tests, as it happens.
We could still have an npm script that uses --watch-path, though, since the scripts are so loosely coupled with the core. It would perhaps give people a reason to upgrade.
I think we should target the oldest active LTS version which would be Node.js 20.x.
The maintenance time for 18.x ends in April 2025.. If we start to switch version at that date we have no time left to deal with any problems in the next version.
Schedule see: https://nodejs.org/en/about/previous-releases#release-schedule
@Jermolene @saqimtiaz ... I did add npm run watch which starts the tw5.com-server edition.
The problem I see is, that the client is not notified, that there is a new server running. But the command seems to work
@Jermolene -- IMO this one can be merged for further testing. -- It only will affect developers -- So users should have no problems
Converted to draft -- It does not work for me anymore.
Sorry had a typo in the command line :/ Everything is OK
... It's not clear why some commands use colon as a separator, some use period, and some use dashes.
-
The dot as a separator is a typo.
-
The colons are used for :info text only
-
The run commands have no separator
@Jermolene
server-external-js is an edition, which could be used with npm run edition --edition=external-js but it would be necessary to rename the directory external-js-server -- Should I rename it?
add some documentation for these npm commands, and transclude it
If do so, then there is no need to put them in fields like wiki:info. Devs will read the readme instead.
Hi @pmario there's a lot going on here, and the net effect is to make our package.json file much longer and more complex.
@Jermolene -- It seems your concern is, that this PR makes the package.json way to complex. That's because the edition and -server directory naming is not consistent. Some editions have it's own -server configuration for testing and some editions do not.
Having an eg: tw5.com and a tw5.com-server configuration is a huge advantage, since the -server test configuration can be significantly different to the published tw5.com directory, which contains the single file settings.
If every edition would have it's own -server configuration it would probably shorten the possible new lines in package.json by 30% or 40%
But that would mean, that the editions directory would contain a lot more subdirectories. The change would be backwards compatible, since the -server directories would be new.
The only directory which would need a name change is the server-external-js because it would need to be external-js-server and external-js
I did not suggest these changes since they would introduce many more edition subdirectories. So it would probably increase the complexity there. But imo it would be much more consistent, which is a good thing.
@Jermolene We only need a decision.
close this one. "merge master" did mess it up :/