question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Should we use namespacing in the CLI

See original GitHub issue

@Microsoft/vscode

https://github.com/microsoft/vscode/issues/92031 is requesting a terminal CLI to enable things like creating a new tab and splitting the current tab which would align with the capabilities of many terminals (including Windows Terminal) and enable splitting a terminal tab by running a command in the terminal.

Does anyone have opinions for or against this? If we want to go with this I think we should also do the same for extensions by deprecating/aliasing the current CLI and moving them to either code ext ... or code extension ... as it keeps growing and could be better organized:

Extensions Management
  --extensions-dir <dir>                            Set the root path for
                                                    extensions.
  --list-extensions                                 List the installed
                                                    extensions.
  --show-versions                                   Show versions of installed
                                                    extensions, when using
                                                    --list-extension.
  --category                                        Filters installed
                                                    extensions by provided
                                                    category, when using
                                                    --list-extension.
  --install-extension <extension-id | path-to-vsix> Installs or updates the
                                                    extension. Use `--force`
                                                    argument to avoid
                                                    prompts.
  --uninstall-extension <extension-id>              Uninstalls an extension.
  --enable-proposed-api <extension-id>              Enables proposed API
                                                    features for extensions.
                                                    Can receive one or more
                                                    extension IDs to enable
                                                    individually.

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:7
  • Comments:20 (17 by maintainers)

github_iconTop GitHub Comments

3reactions
connor4312commented, Jul 19, 2022

As the CLI does more things (server distro, “gateway” mode, version management, terminal work, other things in the future…) I do not think the current model of free-floating flags works very well. Note that when I say CLI here I refer to the interface exposed to users, which is eventually the Rust CLI.

Currently there is top-level help for extension management and flags that only apply to extension management. Adding similar sections for all other functionality causes help to become increasingly verbose and less useful to users, and I think a --help --verbose option does not address the root problem and is obscure to users. I suggest adopting a subcommand approach, where based editor options are shown at the top level (so code --wait foo.txt for instance still works) but the additional functionality I listed previously appears in a subcommand. If I’m a user who knows I want to do things with extensions, I can run code ext --help rather than trying to code --help --verbose | grep -B 5 -A 5 -i extension.

This is the approach I recently took in https://github.com/microsoft/vscode-cli/pull/432 (this is exploration, not final set in stone.) That PR includes logic that handles things that became subcommands (--(list|install|uninstall|)-extensions, --status) in a backwards compatible way.

2reactions
bpaserocommented, Mar 23, 2020

I personally would prefer to not introduce any more capabilities via the CLI other than:

  • opening something (this is what code is for)
  • extension management: simply because this is probably a task that admins want to run headless and it does run headless
  • troubleshooting (I think this is easy to justify)
Read more comments on GitHub >

github_iconTop Results From Across the Web

Platform, default, and cli Namespaces (C++/CLI and C++/CX)
A namespace qualifies the names of language elements so the names do not conflict with otherwise identical names elsewhere in the source code....
Read more >
create a namespace in c++/cli? - Stack Overflow
But I haven't seen any examples of creating my own. So I was wondering if there is a way to declare/create my own...
Read more >
C++/CLI - Lesson 2: Data Types - FunctionX
The C++ Standard provides a namespace called std. The std namespace includes a series of libraries that you will routinely and regularly use...
Read more >
Namespaces - Kubernetes
Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens...
Read more >
get-namespace — AWS CLI 1.27.32 Command Reference
Do you have a suggestion to improve the documentation? Give us feedback. If you would like to suggest an improvement or fix for...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found