volta-cli / volta Goto Github PK
View Code? Open in Web Editor NEWVolta: JS Toolchains as Code. ⚡
Home Page: https://volta.sh
License: Other
Volta: JS Toolchains as Code. ⚡
Home Page: https://volta.sh
License: Other
At least the modules, crates, and primary abstractions should have decent rustdoc comments for MVP.
The installer doesn't have any UI with it. It would make a more pleasant onboarding experience to see a welcome message and a logo, even though there aren't any particular decisions for the user to make.
NodeCatalog::resolve_public
scans for available version of node from the public list, but it doesn't make sure each version it checks is actually available for the current OS. Add this logic to the skip_while
callback.
Every user should have permissions to add shims to the shim/ directory. In Windows since this is in a shared directory, the installer needs to set permissions on that directory to be world-writeable.
How should notion behave for the npm link
usecase?
Imagine project A uses node@6 and project B uses node@8 with project B depending on A
The workflow used would be:
cd projectA
npm link
to make it globally availablecd projectB
npm link projectA
to link it up.The npm versions used in 2 and 4 are different and will cause B not to find A
Need to set up a decent acceptance test harness.
Need an initial implementation for package executables.
We should publish Mac installers as formulae in homebrew.
We need to tighten up the error handling strategy to be sure we always communicate a high-quality error message.
Path to eliminating the hand-written logic for version data structures and for serialization of various data structures:
Use ANSI styling (bold green, right-aligned) for the "Installing" action in the progress bar.
We can't currently do streaming reads from Zip files -- there's an open PR on this for zip-rs but it's been stalled for quite some time.
Until we have a solution to this, we should show a progress spinner in the UI.
For unixes at least, I suspect it would be easier to implement a correct delegation for Tool::exec
by using a Unix exec
call. But this is an area I need to dig into more. (Expert advice welcome!)
notion_core::launch::script_command
is unimplemented.
The readme needs a high-level explanation of shims.
The notion-core
crate is getting pretty unwieldy. A possible reorg to make it a little easier to get a handle on:
installer/
serial/
state/
path/
unix.rs
windows.rs
catalog.rs
config.rs
plugin.rs
shell/
env.rs
style.rs
project/
manifest.rs
mod.rs // was: project.rs
exec/
session.rs
tool.rs
lib.rs
See volks73/cargo-wix#42.
TLDR: the termcolor crate is highly portable and supports multiple versions of Windows.
The guid
crate is nice and reusable. It could be extracted to a separate repo and published to crates.io. It'll need API docs.
I believe fetching the public node listing is causing a pause with no visible indication to the user. Test this hypothesis, and if it's true, we should:
I'm not sure if the caching semantics works, since it could mean missing new versions. So we should think that through.
The Windows installer isn't properly deleting the Node installation directories on uninstall.
We should publish Linux installers in apt.
notion_core::manifest::resolve_node
should consult config file for hooks.
This blocks issue #4.
notion_core::installer::node::Installer::remote()
should put a TeeReader around its input source to save the results to a cache file. The cache file should be stored in a directory specified by notion_core::path::node_cache_dir()
.
WIP, will flesh this out later:
We should consider abiding by the XDG Base Directory Specification
This makes where notion lives on disk configurable, specifically it would abide by the following ENV variables:
$XDG_DATA_HOME
fallback: $HOME/.local/share
$XDG_CONFIG_HOME
fallback: $HOME/.config
$XDG_DATA_DIRS
fallback: /usr/local/share/:/usr/share/
$XDG_CONFIG_DIRS
fallback: /etc/xdg
$XDG_CACHE_HOME
fallback: $HOME/.cache
$XDG_RUNTIME_DIR
fallback see [spec]((https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)
more details for each are specified here*
$XDG
vars (no chroot, containers etc)Technically, likely via the XDG crate
Mostly just a list of whats in my $XDG_CONFIG_HOME
, I suspect there are more.
Where do we put stuff in windows?
Maybe something like:
C:\Users\<username>\AppData\Local\notion-cli\notion\{dirs...}
notion_core::provision::by_version
should consult a node fetch hook.
This blocks issue #4.
Tool::exec
doesn't propagate signals yet.
Need basic functionality for reading user/system configuration. This is where plugins get installed. Should have a basic precedence algorithm for being able to consult the project directory and then the user's configuration directory.
The verbatim
crate only has enough implemented to work on a couple manual test cases. It needs to be completed.
And probably extracted into a separate repo and published to crates.io!
We should generate the msi and deploy it via GitHub releases in the appveyor automation.
A project without "notion"
in its manifest should be treated not as an error but as a project that hasn't opted into using Notion. So in this case it should back off to analogous behavior to existing Node managers, i.e., it should use the globally selected toolchain.
Anything that parses user input, including semver::{Version, VersionReq}
parsing, should produce user-friendly error messages on failure.
We should publish Linux installers as rpms.
This is a tracking issue for the RFC "Node version resolution".
The logic for error reporting and exiting is scattered across the main crate and notion_core. These should be consolidated and unified.
Need an installation shell script for Mac/Linux installation.
Notion should download and cache the latest version of yarn.
A tarball of the latest version of yarn can be found at https://yarnpkg.com/latest.tar.gz
The version for this is located at https://yarnpkg.com/latest-version, which returns a text string (currently 1.6.0
)
From https://yarnpkg.com/en/docs/install#alternatives-stable, this download can be verified like so:
wget -qO- https://dl.yarnpkg.com/debian/pubkey.gpg | gpg --import
wget https://yarnpkg.com/latest.tar.gz.asc
gpg --verify latest.tar.gz.asc
# Look for "Good signature from 'Yarn Packaging'" in the output
style::progress_bar
currently has a hard-coded size of 40, but should be sized dynamically based on the terminal size (which can be computed via the term_size
crate).
We now have a reasonable amount of API doc comments, and I would like to start publishing them on a subdomain of notionjs.com. The URL structure I think I would like to use is:
https://impl.notionjs.com/$version/$variant/*
https://impl.notionjs.com/latest/$variant/*
https://impl.notionjs.com/$variant/*
where $version
is maybe just "$major.$minor"
, $variant
is either "windows"
or "unix"
, latest
is an alias for the current max available version, and the last form is just a shorthand for latest
.
Since these are internal docs, I'd like to include all private definitions. I learned recently that the way to do this is currently nonobvious (I've reached out to some Cargo folks about getting a more standard command-line option in cargo doc
for this):
% RUSTDOCFLAGS=--document-private-items cargo doc --all --no-deps
We'll want automation in both Appveyor and Travis to generate both the Windows and Unix versions (which do differ in a small number of important places!).
Pretty excited about boats' new failure library. Try that out in place of error-chain.
When there's an error in a config file, Volta should print out not just the error message but the relevant lines in the actual source code.
This will require maintaining source location information in the parsers, some of which may not be available from the crates we're currently using. So this one could end up being blocked on getting more full-featured TOML and JSON parsers.
We should respect the cache headers provided by index.json provided by node.
curl -I https://nodejs.org/download/release/index.json
last-modified: Thu, 05 Apr 2018 05:37:38 GMT
etag: "5ac5b622-1bf31"
access-control-allow-origin: *
expires: Fri, 13 Apr 2018 05:44:24 GMT <--- I think we care about this one.
cache-control: public, max-age=14400
In general, they are about a week. But basically always expire before the next Sunday.
Important Scenarios:
https://nodejs.org/download/release/index.json
is accessible, we should download the new artifact, and replace it with the exist.There should be a single module that contains a full encyclopedia of exit codes, and all the error types throughout notion-core
and the main crate should pull their exit codes from that module.
Thanks to @benblank we have an exit codes RFC!
To avoid the complicated conditionals, the session.node()
method should return an enum of which "kind" of Node we got (global vs project). That enum should have a method that produces an Option<Version>
.
This maybe wants to be reconciled with the Installed
type returned by install_node
.
It might be nice to streamline the build/deploy process to use cargo-wix for generating the Windows installer instead of the current command scripts.
Eliminate all FIXME
comments and file them as issues.
We should be testing in Windows with appveyor.
We should be testing in Unix with Travis.
We should publish Windows releases with chocolatey.
The winfolder
crate only has a handful of folders that I needed for the first demo of Notion. It should be finished with the complete set of standard Windows folders.
It should probably also be extracted into its own separate repo and published to crates.io!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.