Describe the bug

In my table of dependencies, the last dependency points to a local project:

[dependencies]
clap = "*"
error_lib = { path = "error" }

The next dependancy table is for rusqlite, which has versions going up to 0.14.0:

[dependencies.rusqlite]
version = "*"
features = ["bundled"]

However, the extension does not understand that this is a new table and thinks we are looking for a dependency called version:

version = "*"    Latest: 3.0.0

To Reproduce
Use this minimal toml file:

[dependencies]
clap = "*"
error_lib = { path = "error" }

[dependencies.rusqlite]
version = "*"
features = ["bundled"]

Open with the extension installed and activated.

Expected behavior
I get the correct version number

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Version: 0.3.3

Additional context
I went a head and looked at the code. It does not reset the isParsingKey flag after parsing an inline table.

VSCode has split the vscode package into @types/vscode and vscode-test. This project should likely be updated accordingly.

Refrences:
microsoft/vscode#71048
https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_36.md#splitting-vscode-package-into-typesvscode-and-vscode-test

I have:

[dependencies]
clippy = { version = "*", optional = true }
log = "0.4"
<...>

[dependencies.clap]
version = "2.32.0"
default-features = false

[dependencies.nom]
version = "4"
features = ["verbose-errors"]

Now crates gets confused and claims the latest version for nom is 2.32.0.

Describe the bug
If viewing Cargo.toml with conflicts in it, VSCode will display an error message after almost every interaction.

In the status bar there's the "Crates: Completed with errors" message.

To Reproduce

1. View Cargo.toml with conflicts (rebase, merge)
2. Click on the editor window or try and save the file
3. An error dialog box should appear, like the one in screenshots

Expected behavior
The extension should suppress the error message

Screenshots

Desktop (please complete the following information):

• OS: Linux Ubuntu
• Version 18.04.3 LTS x86_64

Additional context

code --version
1.39.2
6ab598523be7a800d7f3eb4d92d7ab9a66069390
x64

Disabling the extension eliminates this bug

Crates from alternative registries are parsed as comming from crates.io so the versions shown are from crates.io instead of the altenarive registry but also if the package doesn't exist in crates.io an error is shown every time the file is modified

To Reproduce

Add a crate from an alternative registry which has a different max version there than in crates.io or doesn't exist in crates.io, only in the alternative registry

Expected behavior
Ideally that versions are parsed from the alternative registry but at least that the alternative registry is detected so those crates don't show any max version and no error is shown if they don't exist in crates.io as happens with packages from git sources

Platform:

• OS: linux (should happen in other platforms)
• Version 0.3.7

Additional context
alternative registries are still not stable but will be in the next release, 1.34

Again, a matter of taste:

May allow users to configure github token

Describe the bug

The wrong version is reported as latest for the "cargo" crate when listed as a dependency

To Reproduce

Include cargo as a dependency in Crates.toml

Expected behavior

The "crates" extension would show me the current latest version of the cargo crate, which at this time is 0.34

Screenshots

Desktop (please complete the following information):

Fedora 29
"Crates" extension version 0.41

Hi, this is really nice work! It's something we often get requests for in the RLS. Would you be interested in integrating this either with the Rust VSCode plugin or with the RLS itself? RLS integration would be better since it would make the features available with other editors (Atom, Eclipse, etc), however, I imagine it would be a bit more work to port this to working on the language server.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:
I started with the yew dashboard example's cargo file.

[package]
name = "dashboard"
version = "0.1.0"
authors = ["Denis Kolodin <[email protected]>"]
edition = "2018"

[dependencies]
failure = "0.1"
serde = "1"
serde_derive = "1"
yew = { path = "../..", features = ["toml"] }

I wanted to replace it with version="1" to try and get a list instead of the path= parameter, and the rendering got a bit borked, to say the least.

Expected behavior
I'd expected the rendering to not bork... Also, while editing the format for the file may have been invalid, which may have effected things.

Screenshots

Desktop (please complete the following information):

• OS: macOS High Sierra
• Version 10.13.3

Describe the bug
A clear and concise description of what the bug is.

When I added deps or dev-dep to Cargo.toml, it will report errors every time I open or save it.

Desktop (please complete the following information):

• OS: win10
• VSC version: 1.39.2

The new sorting of versions is text-based, and not numerical. For example, version 0.9.2 of the syn crate is reported as before version 0.15.30. It even recommends to change the up-to-date version with the wrong, outdated one. I believe this was caused by e7b69ff.

In a cargo.toml file, there is a dependency:
ipfs-api = "0.5.0-alpha2"

VSCode continuously gives the error "Fetch Errors: ipfs-api" ONLY on this crate. I suspect it has something to do with the "-alpha2" extension. There are other crates that may have a "-alpha"-like extension as well and it would be nice if it were handled.

The plugin does not propose versions of crates when the following lines are added above the [dependencies] section :

[profile.release]
# Include line numbers even in release ([optimized + debuginfo])
debug = 1

Note that subsequent sections do work :

[dependencies.xxx]
version = "0.x.x"
features = ["xxxx"]

It took me some time to notice because I had disabled the thumbs up icon.

serde-derive doesn't exist (it's serde_derive), but the extension still recognize it.

    Updating registry `https://github.com/rust-lang/crates.io-index`
error: no matching package named `serde-derive` found
location searched: registry `https://github.com/rust-lang/crates.io-index`

Describe the bug
I am not sure of the reason but it looks like using a dependency with a key starting with an uppercase char causes an error.

To Reproduce
Just try with Inflector as dependency (with uppercase 'I').

# ...

[dependencies]
Inflector = "0.11.4"
# ...

Desktop (please complete the following information):

• OS: ArchLinux
• Rust: 1.39.0-nightly
• Cargo: 1.39.0-nightly

A version in Cargo.toml like ^2 will match versions >=2 and <3. So it should show with a 👍 when the current version in crates.io is 2.5, but instead I get this:

pest = "^2.0"  Latest:2.1.0
pest_derive = "^2.0" Latest:2.1.0

However, cargo build is actually using 2.1.0.

Describe the bug
If you have a dependency on a crate where the latest version of that crate have been yanked, the crates plugin will show that the latest yanked version is available, instead of latest available version.

To Reproduce
Add a dependency on latest available futures crate:

futures = "0.1.21"

Note that the crates plugin shows that a later 0.2.1 version is available, even though it has been yanked

Expected behavior
I would expect the plugin to ignore yanked versions of crates and only show the latest actually available crate.

This is not really a major issue, but thought I would report it. Thanks for an awesome plugin!

Describe the bug
When I hover over the version of a crate, I see the list of possible versions to choose from as expected. Then I accidentally choose a version I didn't mean to choose. When hovering over the incorrect version, I still get the list as expected, but now I cannot select the correct version I originally meant to select. The only way I can select the correct version is if I save the file first.

Expected behavior
To be able to change the version as many times as I want without needing to save the .toml file between each selection.

Desktop (please complete the following information):

• OS: Windows 10
• Version 0.3.4

Describe the bug
When using futures-preview (currently at release 0.3.0-alpha.2) crates is suggesting that I instead use the Latest: 0.2.2. While I'm totally fine with the general suggestion to use 0.2.2 as the newest non-alpha version, I'd rather not have a warning for something that is ahead of it.

To Reproduce
Steps to reproduce the behavior:

1. Start a new project
2. Add futures-preview = "0.3.0-alpha.2" to the [dependencies] block

Expected behavior
Shows a thumbs up indicating I have a version newer than the latest.

Screenshots

And finally, thank you for this extension! I'm a huge fan.

Describe the bug
Earlier versions appear as "newer" than later versions if they were published to crates.io later.

To Reproduce
Add aerosol as a dependency - 0.2.0 appears as older than 0.1.3. (Because 0.1.3 was published more recently)

Expected behavior
0.2 should appear newer than 0.1.3

Due to limitations of the toml parser code has lots of regex and performance may be damaged by that.

See microsoft/vscode-remote-release#957

• Issue Type: Performance
• Extension Name: crates
• Extension Version: 0.4.2
• OS Version: Darwin x64 18.5.0
• VSCode version: 1.33.1

⚠️ Make sure to attach this file from your home-directory:
⚠️/Users/pllllth/serayuzgur.crates-unresponsive.cpuprofile.txt

Find more details here: https://github.com/Microsoft/vscode/wiki/Explain:-extension-causes-high-cpu-load

When some creates.io request is failing, e.g. due to missing internet connectivity or some non-existing crate name, the situation is just silently handled w/o showing an error notification and w/o removing the Fetching crates.io message in the status bar. So the user has no idea what's actually going on...

Describe the bug
An error popup is shown every time the file is modified when using a crate that only has prerelease versions published.

Similar to #41.

To Reproduce
Add a crate that has only had prerelease versions published. Example:

tonic = "0.1.0-alpha.3"

Expected behavior
Non-focus stealing error (an inline error displayed in the toml file?)

Screenshots

Desktop

• OS: Win 10 + SSH remote extension
• Version: 1.40.0-insider

Actual behavior
This extension suggests yanked versions as latest version. Prime example is the futures crate.

Expected behavior
futures crate should have 0.1.26 as latested version

Describe the bug
With this dependency:

simple-file-cache = {git="https://github.com/izderadicka/simple-file-cache.git", features=["asynch"], version="0.1.2", optional=true}

extension show error (Fetch errors: simple-file-cache) after each change in Cargo.toml.
Problem here is that dependency is now only in git, not yet in crates.io.
cargo tool is OK with it, just using available dependency from git.
(I think it's same as in documentation where dependency has both path and version keys)

To Reproduce
Add the dependency above to your Cargo.toml

Expected behavior
I think in this case it should ignore error from crates.io - not to show error notification and "Crates completed with errors on status bar" as this is a legitimate situation. cargo tool is also OK about it.

Screenshots

Here is error stacktrace from dev console:

/usr/share/code/resources/app/out/vs/workbench/workbench.main.js:294 [Extension Host] StatusCodeError: 404 - "{\"errors\":[{\"detail\":\"Not Found\"}]}"
	at new StatusCodeError (/home/ivan/.vscode/extensions/serayuzgur.crates-0.3.5/node_modules/request-promise-core/lib/errors.js:32:15)
	at Request.plumbing.callback (/home/ivan/.vscode/extensions/serayuzgur.crates-0.3.5/node_modules/request-promise-core/lib/plumbing.js:104:33)
	at Request.RP$callback [as _callback] (/home/ivan/.vscode/extensions/serayuzgur.crates-0.3.5/node_modules/request-promise-core/lib/plumbing.js:46:31)
	at Request.self.callback (/home/ivan/.vscode/extensions/serayuzgur.crates-0.3.5/node_modules/request/request.js:185:22)
	at emitTwo (events.js:126:13)
	at Request.emit (events.js:214:7)
	at Request.<anonymous> (/home/ivan/.vscode/extensions/serayuzgur.crates-0.3.5/node_modules/request/request.js:1161:10)
	at emitOne (events.js:116:13)
	at Request.emit (events.js:211:7)
	at IncomingMessage.<anonymous> (/home/ivan/.vscode/extensions/serayuzgur.crates-0.3.5/node_modules/request/request.js:1083:12)
	at Object.onceWrapper (events.js:313:30)
	at emitNone (events.js:111:20)
	at IncomingMessage.emit (events.js:208:7)
	at endReadableNT (_stream_readable.js:1056:12)
	at _combinedTickCallback (internal/process/next_tick.js:138:11)
	at process._tickCallback (internal/process/next_tick.js:180:9)

and error notification:

Desktop (please complete the following information):

• Linux, VS Code 1.19.1, Crates ext. v. 0.3.5

Describe the bug
Using VSCode nightly (version Version 1.30.0-insider (1.30.0-insider), cd5b4d1bb3fc7e509fba077095b2b280b8ff7161), any changes to Cargo.toml triggers a notification popup saying "Fetch errors: …". Extension version is 0.3.5

Screenshots
http://take.ms/g9qT9

Desktop (please complete the following information):

• OS: OS X Mojave

Last (of many) error in the dev console:

[Extension Host] RequestError: Error: write EPROTO 4650448320:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:../../vendor/node/deps/openssl/openssl/ssl/s23_clnt.c:802:

	at new RequestError (/Users/dvd/.vscode-insiders/extensions/serayuzgur.crates-0.3.5/node_modules/request-promise-core/lib/errors.js:14:15)
	at Request.module.exports.plumbing.callback (/Users/dvd/.vscode-insiders/extensions/serayuzgur.crates-0.3.5/node_modules/request-promise-core/lib/plumbing.js:87:29)
	at Request.RP$callback [as _callback] (/Users/dvd/.vscode-insiders/extensions/serayuzgur.crates-0.3.5/node_modules/request-promise-core/lib/plumbing.js:46:31)
	at Request.init.self.callback (/Users/dvd/.vscode-insiders/extensions/serayuzgur.crates-0.3.5/node_modules/request/request.js:185:22)
	at emitOne (events.js:116:13)
	at Request.emit (events.js:211:7)
	at Request.onRequestError (/Users/dvd/.vscode-insiders/extensions/serayuzgur.crates-0.3.5/node_modules/request/request.js:881:8)
	at emitOne (events.js:116:13)
	at ClientRequest.emit (events.js:211:7)
	at TLSSocket.socketErrorListener (_http_client.js:387:9)
	at emitOne (events.js:116:13)
	at TLSSocket.emit (events.js:211:7)
	at onwriteError (_stream_writable.js:408:12)
	at onwrite (_stream_writable.js:430:5)
	at cb._destroy (internal/streams/destroy.js:39:7)
	at TLSSocket.Socket._destroy (net.js:561:3)
	at TLSSocket.destroy (internal/streams/destroy.js:32:8)
	at WriteWrap.afterWrite [as oncomplete] (net.js:869:10) (at dependencies.map.api_1.versions.then.catch (/Users/dvd/.vscode-insiders/extensions/serayuzgur.crates-0.3.5/out/toml/listener.js:38:21))
t.log @ console.ts:134
t._logExtensionHostMessage @ extensionHost.ts:451
(anonymous) @ extensionHost.ts:243
emitTwo @ events.js:126
emit @ events.js:214
emit @ internal/child_process.js:772
_combinedTickCallback @ internal/process/next_tick.js:141
_tickCallback @ internal/process/next_tick.js:180

2. Remove the current line:

3. Press Enter, Home:

4. Undo twice:

Describe the bug
A clear and concise description of what the bug is.

I've recently split up a cargo project into workspaces with a cli package refering to a lib package by path. When I remove the reference by path the crates ext is successful. When added back I get a stream of error dialogs about it failing and screen of flickering thumbs!

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'

Setup a cargo workspace project with at least two package and at least one package referencing another by path

4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Crates extension understands that the dependency exists locally retry with error dialogs.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS] osx
• Version [e.g. 22] 0.3.2 (latest at this time )

Additional context
Add any other context about the problem here.

trying to split up a mono cargo package into separate lib and cli packages with a workspace

https://github.com/serayuzgur/crates/blob/master/src/test/full.toml is missing examples for separate [dependencies.*] tables not related to a specific [target...], e.g.:

[dependencies.libc]
version = "..."

Relates to #17

This vscode extension is great at parsing crates specified in [dependencies]. Unfortunately it seems to ignore crates specified in [bin-dependencies]. Any plans on supporting this?

log = "0.4" should be the same as log = "0.4.2".

This is already mentioned in the README, of course.

Describe the bug
vs code shows Fetch Errors for crates Extension

To Reproduce

1. Go to 'Cargo.toml'
2. Below [dependencies], add new line nom = "4.1.1"
3. See vs code error popup.

Expected behavior
crates works before, which shows thumbs-up unicode char next to dependency version.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Version: Build 1803

Additional context
It was all right yesterday. The only manual change I made was enabling Format on Save feature of vs code, which doesn't seem to fix the issue if toggled back.

We're periodically seeing abnormal spikes in traffic that originate from this plugin. It appears to send a request for every crate it wants to know about concurrently, with no limiting of any kind in place. We're frequently seeing upwards of 50+ concurrent requests from the same IP identifying as this plugin.

This is in violation of the crates.io crawler policy. At minimum these requests need to be sent serially rather than in parallel.

Thank you for setting a proper user-agent header so I am able to reach out without having to resort to blocking traffic

vs.

When open project with dependencies

[package]
name = "test_deps"
version = "0.1.0"

[dependencies]
"nibble_vec" = "0.0.4"
normalize-line-endings = "0.3.0"

TOML format support keys Quoted keys
https://github.com/toml-lang/toml#keys.

"nibble_vec" = "0.0.4" - valid.

[dependencies]
cookie_rs = {package = "cookie", version = "0.11"}

The extension fails to version check that, with the message "Fetch Errors: cookie_rs".

Not sure if it's my cold, but this makes me a little dizzy:

Decoration is like "Latest: xx.xx.xx". It will be better if it becomes customizable.

E.g. after a git checkout Cargo.toml:

This is a cool extension, but it only helps with 2 of the dependencies specified in winit's Cargo.toml.

Notably, it doesn't work on image = { version = "0.19", optional = true }, nor platform-specific sections:

[target.'cfg(target_os = "macos")'.dependencies]
objc = "0.2"
cocoa = "0.14"
core-foundation = "0.5"
core-graphics = "0.13"

This is a matter of taste, arguably.

when viewing the version list with crates 0.0.11 and with VSCode 1.24, the version list shows the version numbers, but also what appears to be the code that is responsible for the clicking functionality. for example, for serde, The list looks something like this:

Available Versions

• [1.0.66](command:crates.replaceVersion?{"item":"serde = "1.0.66"","start":116,"end":132})
• [1.0.65](command:crates.replaceVersion?{"item":"serde = "1.0.65"","start":116,"end":132})
• [1.0.64](command:crates.replaceVersion?{"item":"serde = "1.0.64"","start":116,"end":132})
• [1.0.63](command:crates.replaceVersion?{"item":"serde = "1.0.63"","start":116,"end":132})
• [1.0.62](command:crates.replaceVersion?{"item":"serde = "1.0.62"","start":116,"end":132})
  ... etc.

I'm seeing that we're still hitting the rate limit for nushell (https://github.com/nushell/nushell).

Something I've noticed using both v3 and v4 APIs for GitHub is that with v3 it's pretty easy, even with authentication, to hit your rate limit. Since you can only send one query at a time, you end up naturally hitting it unless you add artificial delays in the queries.

At one point working with the GitHub API to track language popularity, I moved my tool over to the v4 APIs. Here's an example of the kind of query string I'd use:

{"query": "query { lang0: search(type:ISSUE, query: \"language:JavaScript type:pr created:2019-11-04..2019-11-11\") { issueCount } lang1: search(type:ISSUE, query: \"language:Java type:pr created:2019-11-04..2019-11-11\") { issueCount } }"}

Which is this bit of GraphQL:

query { lang0: search(type:ISSUE, query: "language:JavaScript type:pr created:2019-11-04..2019-11-11") { issueCount } lang1: search(type:ISSUE, query: "language:Java type:pr created:2019-11-04..2019-11-11") { issueCount } }

When that's run, each answer gets a label attached to it that can be queried back out. This lets you run a bunch of queries all at once and it's generally much easier to stay in your rate limit this way (v4 rate limits work differently than v3).

The Marketplace badge links to GitHub, while the Downloads badge links to Marketplace. This might be intentional, but it's a tiny bit confusing 😄.