Comments (5)
These additions are welcome in my opinion.
Note to those who are interested in contributing in these areas: Please also consider contributing in Pseudo Terminal support in Deno ( denoland/deno#3994 ). Deno currently doesn't have a practical way to test terminal interactions (as far as I know) and testing these features are very difficult/tricky.
from deno_std.
I tend to agree with @iuioiua here. I would generally like high quality and flexible building blocks in @std
as a general rule of thumb. cliffy
already has a full set of high quality tools needed to build a feature rich CLI experience. I'd be less apt to mix and match parts of @std
and other libraries as this might provide a less holistic feel. That said, if @std
included a full suite of rich and powerful CLI features that would potentially be a different story. Anything in between is not worth it imo.
from deno_std.
I would not exclude a commonly used feature as this that makes the tools list more complete just because the tools list is not complete (yet).
This is my opinion of course, but let me try and clarify my stance.
My concern here is figuring out the balance of what goes into @std
and what does not. I've been watching various issues and PRs over the last few months and often see dialogue and debate around what should and shouldn't be part of @std
for various reasons. From what I've seen (which could be my misguided perspective), is that there is a tendency to keep things to a minimal API surface. On one side, this makes a lot of sense since @std
provides building blocks for other libraries and apps. Having a large API surface could lead to complexity and make it harder to evolve. However, there is a grey area where some of these types of tools (e.g. select input) become quite opinionated and difficult to strike that balance where everyone can agree.
When I choose libraries to use, I try to be cognizant of how well they will evolve with my project. If I'm starting a CLI project, I want to pick a feature rich library up front, so I can avoid limitations that might cause me to have to rewrite or switch out libraries later. My worry is that some tools like the input select, etc. could easily fall into the grey area describe above. Especially given they are opinionated in a way that is directly exposed to the end user versus internal code.
Here is my current opinions on the existing cli tools:
colors
- Useful. I also like howcliffy
builds on top of this to create a fluent API, which is often more readable to use when composing things imo.(built in prompt)
- I'm not sure what is meant here but I suspect this iswindow.input
maybe?secret prompt
- There are not a lot of ways you can do this so probably doesn't require many additional featuresan argument parser based on mimist
- I've describe my thoughts here. Overall, I find this API not very intuitive and overly simplistic to be very useful.spinner
- A decent start, but it could use some additional states beyond start/stop (e.g. info, fail, warning, succeed) to show progress/completion. If there is appetite, I might be willing to contribute this.- #4362 - I like the direction of this so far and would hope to see the minimist arg parser replaced with this. That said, it's a slippery slope as this can get very opinionated with a lot of nuances since it's end user facing when you get into sub commands, etc.
To summarize, I'm not against having a full suite of CLI tools in @std
. I just hope this is done with a clear intention and roadmap that avoids too much friction evolving the APIs and tools. Essentially, a go big or go home mentality for this class of tools building CLIs. Otherwise, I'd personally stick with a full suite in userland for most things (e.g. cliffy
).
from deno_std.
cliffy already does this. Simple/basic CLI helpers make sense in the Standard Library, but there is a point when we should not go further. I'd prefer not to have this in the Standard Library.
from deno_std.
I tend to agree with @iuioiua here. I would generally like high quality and flexible building blocks in
@std
as a general rule of thumb.cliffy
already has a full set of high quality tools needed to build a feature rich CLI experience. I'd be less apt to mix and match parts of@std
and other libraries as this might provide a less holistic feel. That said, if@std
included a full suite of rich and powerful CLI features that would potentially be a different story. Anything in between is not worth it imo.
@std
already provides some major cli tools:
- colors
- (built-in prompt)
- secret prompt
- an argument parser based on minimist
- spinner
- (#4362 as an alternative take on argument parser with possible auto help generator as a second step)
I would not exclude a commonly used feature as this that makes the tools list more complete just because the tools list is not complete (yet).
from deno_std.
Related Issues (20)
- stabilize `@std/net`
- stabilize `@std/http`
- stabilize `@std/fs`
- stabilize `@std/json`
- stabilize `@std/testing`
- stabilize `@std/jsonc`
- stabilize `@std/csv`
- stabilize `@std/semver`
- stabilize `@std/expect`
- stabilize `@std/yaml`
- stabilize `@std/front-matter`
- stabilize `@std/ini`
- stabilize `@std/dotenv`
- msgpack: non-string/non-number key supprt
- `describe` should throw if passed a function that returns a promise HOT 2
- Add cli for dotenv like npm dotenv-cli HOT 1
- `@std/cli`: Support multiple spinners at the same time HOT 9
- Support Cookies Having Independent Partitioned State (CHIPS)/Partioned cookies in http/cookie.ts HOT 1
- deleteCookie doesn't allow deleting cookies with the SameSite, Secure or unparsed attributes set
- proposal: drop `std/io` from the first stabilization targets HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from deno_std.