volta-cli / website Goto Github PK

On desktop/laptop at pretty normal window sizes, the footer contents look weirdly spread out. Restrict the footer contents to be limited to the same max-width as the main page contents.

The footer is missing from the docs. subdomain!

The docs. subdomain currently has a wonky index page. It should have a simple index page linking to the various guides.

This addresses the persona of a user who wants to try a new tool, but doesn't want to have their filesystem mutated in unexpected ways.

At Advanced > Installers > Skipping Volta Setup, it currently shows:

Skipping Volta Setup

If you wish to run the installer but do not want your profile scripts modified by volta setup, you can pass the --skip-setup option to the installer:

curl https://get.volta.sh | bash -s -- --skip-setup

NOTE
We don't currently support skipping volta setup on Windows.

However, this leaves the user's installation in a non-functional state and doesn't provide any guidance on how to manually enable functionality.

Based on a glance at the Rust setup module, it seems like user simply needs to set a persistent environment variable for VOLTA_HOME, and extend their PATH with $VOLTA_HOME/bin. (Did I overlook something?)

It would be helpful to include the above information in that section, and inform the user that setting them in advance of the installation will customize the install root.

Further, it would be useful to explicitly document the FS roots for all mutations which occur during installation, so that a cautious user who can't read the Rust source can be made aware and act accordingly. This seems partially in place (see Windows Installer and Unix Installer), but the text in those descriptions aren't comprehensive of all mutations (e.g. the shims directory on each platform is not included in the listed paths).

Do a full pass across the reference docs to match the current volta help output.

We're going to remove volta current from the command set for now; update the docs accordingly.

Documentation says that {{version}} is only available in the template for distros but the examples on the same page use it within an index.

The GitHub link in the header nav has an SVG icon indicating it's a cross-domain link. That icon should be part of the a-tag but shouldn't be underlined.

Should be 0.4.0

Need a reference page for volta which.

Need a reference page for volta completions.

Some policy details in how Volta works aren't current documented. Off the top of my head:

• How volta install <package> chooses an engine.
• How Volta resolves shims.
• Ways to override defaults.

I am AkarinLiu from China, If Chinese documents can be provided, it will benefit at least hundreds of millions of developers in the future.

The version command docs were removed but are still listed from the nav metadata, which is creating some bugs in the site.

I'd like to replace the following in my repos:

1. Install a node version manager:
   * Linux/OSX - https://github.com/nvm-sh/nvm
   * Window 7 - https://github.com/nullivex/nodist
   * Windows 8+ - https://github.com/coreybutler/nvm-windows

with

1. Install a node version manager:
   * https://volta.sh

But there is no documentation for what specific OS's you do and don't support. Which makes me very leary to even try Volta. All I can find is "we support everything!" which... of course you don't, you don't work on Windows 95, and that's fine. I just wanna know what you do and don't support, bonus if you say how long you'll continue supporting an OS version.

This should be in the documentation on the website in the sidebar as "OS Support" with a detailed list of all the OS's. Or at the very least in the README.md.

Example:

• https://github.com/nwutils/create-desktop-shortcuts#os-support

The title tag contents are minimal. At least include the tagline?

The activate/deactivate commands are meant for alpha and development use but not for the final end product. We've removed them from the CLI help and they should be removed from the online docs too.

I had a great conversation with @chancancode about using Volta in CI. The main takeaway was we should have instructions in the docs for how to use Volta in CI. But it turned out to be nontrivial and we should spend some time polishing the user experience and testing it out in popular CI systems (Travis, Circle, Azure Pipelines, and GitHub Actions). We should also have doc pages or sections for each of these popular CI systems.

Some of the challenges Godfrey ran into:

• In Travis, the setup command curl | bash silently fails sometimes because of something about how Travis does download caching.
• Since installing Volta requires opening a new shell to get the persisted changes to the environment, you can't install it and use it in the same shell. What should we recommend here?
  • Manually make the env changes in CI?
  • Some kind of CI installer that spits out commands to eval or source in the CI yaml?
  • Should we move the volta executable to VOLTA_HOME/bin?
  • Can we eliminate the function wrapper soon?
• How should we interact with build matrices? It would be nice to be able to choose different tool versions via VOLTA_* env vars, but we should think about whether this kind of precedence algorithm (overriding local config with an env var) could be problematic.

For reference, here's a fairly minimal travis config Godfrey is using for his project, where he got Volta working.

Hi, the Windows installation note specifies that you must either:

• Enable Developer Mode (recommended)
• Run Volta with elevated privileges (not recommended)

I'm currently on Windows 21H1 managed by my company, and didn't do either. Everything seems to work fine. But there might be some features I haven't tried yet?

I suggest the note should be changed depending on why it was added in the first place, so the users don't activate anything they don't need:

• If it's required on older versions of Windows, that version should be specified
• If it's required by some features, change the wording from must to might, and specify which features needs it to work
• Remove it entirely if none of these longer apply

It may be a good idea to add testimonials to Volta front page. For example:

Armin Ronacher:

We’re using Volta for a long time now and it’s so good that i often forget i use it. That’s the best kind of tool. It just works.

https://news.ycombinator.com/item?id=27023817

I've added smaller versions of the wordmark image to the assets repo:

• https://github.com/volta-cli/assets/blob/master/wordmark-338x150.png
• https://github.com/volta-cli/assets/blob/master/wordmark-72x32.png

We should update the site to use those in order to optimize page loads.

Assuming we go forward with volta-cli/volta#412, update the docs accordingly.

The volta install output is out of date from the actual output from the command. It could also use some explanatory text elaborating how it works.

Versions should be specified as e.g. node@12 instead of node 12 in the docs.

The docs site gets its example tools' versions from _data/versions.json. This can be automatically determined by fetching metadata from public indexes/registries at jekyll build time.

I got advice from a certified Person Who Actually Knows CSS that if we make mobile the default settings, then the cascade's specificity rules will work better for us. This will require a fairly significant refactor of the styles.