2024-02-01 Meeting

[lucacasonato]

• CLI proposal (@CanadaHonk)

[lucacasonato]

Notes:

• @CanadaHonk: presenting cli proposal
  • @lucacasonato: let's move to wintercg. This is a useful thing to standardize. Specifically args and env are something commonly used.
  • @andreubotella: having a shared set of cli tools would be good
  • going through cli apis: What CLI APIs are there? proposal-cli-api#1
    • @Ethan-Arrowood: isatty, interactive handling, color support
    • @andreubotella: colors could be done using console.log %c, but this requires tools parse css. is that too much?
    • @Ethan-Arrowood: color/support mode handling (FORCE_COLOR=1 NO_COLOR=1)
    • @Ethan-Arrowood: should this be extended to flag parsing, man generation, --help generation etc
  • should we standardize process?
    • @lucacasonato: i don't think so - there is too much node specific stuff being pulled in. for example, node streams and EventEmitter instead of whatwg streams and EventTarget
    • @Ethan-Arrowood: look at tools like the vercel API to see what is commonly used. maybe we can introduce a new global that duplicates info with process
    • @littledan: we should try to not invent new things if the old thing works fine. maybe process.argv? the rest probably not.
  • should argv include runtime parts: Should argv include runtime parts (binary/script/runtime args)? proposal-cli-api#3
    • @lucacasonato: no, it makes it to difficult to write portable code. see my issue comment
    • @andreubotella: i agree with luca, this is also a problem for single executable binaries executing javascript. they may differ from regular deno / node invocations, even though they use those runtimes under the hood
    • @littledan: this convinces me that a new api makes sense.
  • @littledan: is autocomplete / arg parsing in scope
    • @lucacasonato: I think in the limit, yes. but first we should work on low level apis that allow you to implement this in userland. Once we have those, we can work on higher level APIs in the spec.
    • @CanadaHonk: agreed, first support userland, then we can work on higher level apis in spec.
    • @littledan: this makes sense
  • what namespace: What namespace? proposal-cli-api#2
    • @lucacasonato: navigator.process?
    • @littledan: we shouldn't hang things not relevant to browsers off navigator
    • @CanadaHonk: navigator.process and process are confusing - shouldn't have two things with the same name
    • @lucacasonato: suggest we check other runtimes
  • @lucacasonato: next steps: write a explainer, pass to Node.js and Bun to get feedback on the idea
• @andreubotella: merged the navigator-registry, please review and open issues at https://github.com/wintercg/navigator-registry
• @littledan: submitted to ecma the documents necessary for WinterTC formation. nothing to report yet. initially scheduled for quarterly meetings because the work there is not design work, but just the pro-forma standardization. if anyone wants to join as an invited expert, please ping @littedan