Open gajus opened 1 year ago
This is a problem when running multiple Turbowatch scripts, e.g. turbowatch **/turbowatch.ts
turbowatch **/turbowatch.ts
If the above execution produces these logs:
[13:12:10.202] 0ms debug @turbowatch #subscribe: generate (0ee94688): initial run... [13:12:10.204] 2ms debug @turbowatch #subscribe: generate (0ee94688): started task [13:12:10.204] 0ms debug @turbowatch #subscribe: build (c82d7857): initial run... [13:12:10.205] 1ms debug @turbowatch #subscribe: build (c82d7857): started task
then there is no way of knowing which instance of turbowatch.ts these logs are originating from.
turbowatch.ts
I think the solution is quite simple here. We just need to allow name property in defineConfig and prepend that to the trigger name, e.g.
name
defineConfig
[13:12:10.202] 0ms debug @turbowatch #subscribe: slonik:generate (0ee94688): initial run... [13:12:10.204] 2ms debug @turbowatch #subscribe: utilities:generate (0ee94688): started task [13:12:10.204] 0ms debug @turbowatch #subscribe: utilities:build (c82d7857): initial run... [13:12:10.205] 1ms debug @turbowatch #subscribe: slonik:build (c82d7857): started task
My slight problem with this is that adding a variable length prefix will break log alignment. Something that needs to be considered if we want to maintain pretty output.
This is a problem when running multiple Turbowatch scripts, e.g.
turbowatch **/turbowatch.tsIf the above execution produces these logs:
then there is no way of knowing which instance of
turbowatch.tsthese logs are originating from.I think the solution is quite simple here. We just need to allow
nameproperty indefineConfigand prepend that to the trigger name, e.g.My slight problem with this is that adding a variable length prefix will break log alignment. Something that needs to be considered if we want to maintain pretty output.