When a newer vSphere version is encountered, an error is thrown about vsphere-connect HOT 11 CLOSED

I'm actually re-writing this library to not rely on vsphere-schema. Please test out the chain branch https://github.com/bhoriuchi/vsphere-connect/tree/chain

The usage is a bit different and the new API is not completely set in stone as I am working on the re-write in my spare time. There are several examples in the examples directory on that branch. The chain branch also caches the parsed wsdl data so the performance should be much better than the current code.

from vsphere-connect.

That branch immediately fails with:

Error: Cannot find module 'soap'
    at Function.Module._resolveFilename (module.js:326:15)
    at Function.Module._load (module.js:277:25)
    at Module.require (module.js:354:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/path/to/vsphere-connect/lib/index.js:15:14)
    at Module._compile (module.js:410:26)
    at Object.Module._extensions..js (module.js:417:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Module.require (module.js:354:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/path/to/myfile.js:3:17)
    at Module._compile (module.js:410:26)
    at Object.Module._extensions..js (module.js:417:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)

It looks like it's still requiring the "soap" module even though that module is no longer listed as a dependency.

Adding a dependency on "soap" (by copy+pasting the dependency from master), I get "Cannot find module 'nodexml'". "soap-cookie" and "vsphere-schema" are similarly still required, even though they have been removed from package.json.

Finally, after adding these 4 missing dependencies to my package.json, creating a client pointing at an ESXi 6.5 host fails with the exact same error as before: "Unhandled rejection TypeError: env.versions.join is not a function" from getSchema.

I did not see anything different in the example directory on your branch compared to master. Perhaps I am missing something?

from vsphere-connect.

Hmm, I see a new src directory, but attempting to require('vsphere-connect/src') fails with

> require('vsphere-connect/src')
/path/to/foo/node_modules/vsphere-connect/src/index.js:1
(function (exports, require, module, __filename, __dirname) { import client from './client/index'
                                                              ^^^^^^
SyntaxError: Unexpected reserved word

...so it seems like the src directory is written in something my node.js does not understand.

I see 'babel' listed as a dev dependency, but I don't see where you've committed/uploaded the transpiled source that's compatible with the normal node.js runtime. Is it published under a different module name, or in another directory?

Or did you want me to perform a local checkout of your code and publish it somewhere myself? At the moment I've just updated my package.json to point at the latest commit on your branch, which does not appear to be working particularly well ("vsphere-connect": "bhoriuchi/vsphere-connect#88cdc702")

from vsphere-connect.

I just need to update the package with a build. I'll try to get that committed tonight

from vsphere-connect.

Thanks. I've never played with babel so I don't have the first clue how to get it up and running.

from vsphere-connect.

ive added a build and updated the package.json. the examples i was refering to are in /src/examples. unfortunately im running into a bug withthe build library i use rollup and dont have time at the moment to test. It did however build so feel free to test. i will try to test the build tomorrow

from vsphere-connect.

Looks like that works. The new API isn't quite what's documented on https://github.com/bhoriuchi/vsphere-connect/wiki/API-V2 (e.g. .logout() does not return a Promise, you have go .logout().run() to actually log out), but it definitely works against ESXi 6.5.

It looks like not all of the functionality is exposed through the top-level API at the moment (e.g. the 'reload' method needs you to chain down to v.client()), but it does solve the problem in this ticket. Thanks very much!

from vsphere-connect.

Yeah, I'm still working on the rewrite and documentation. It's a side project so it's a little more slow going. I'll keep this open till I publish a release

from vsphere-connect.

I did notice that when there's an error from .reload(), even if I .catch(...) the Promise I still end up with a warning about an unhandled rejection (e.g. "Unhandled rejection (<{"faultCode":"ServerFaultCode","messag...>, no stack trace)" from Bluebird).

It looks like it's because client.reload(...) creates a Promise then calls client.method(...), and client.method(...) also creates a Promise. The Promise from client.method(...) isn't actually used, and never has any error handlers attached to it, because client.reload(...) passes a callback instead of calling .then() on the return value. So when client.method(...) rejects its Promise, bluebird gives a warning that nothing handled the rejection (even though your code propagates the error up to the Promise from client.reload(...)).

You might want to remove the dual functionality of Promise-y methods that are sometimes passed callbacks - if anybody needs callback functionality, they can call .asCallback(callback) on the Promise your methods return. Alternatively, you could call .asCallback(callback) yourself from all such dual-purpose methods (which will stop Bluebird complaining about unhandled errors) and avoid the utility methods resultHandler and errorHandler.

Edit: or the error might be the other way around - the Promise code in client.reload() does return the Promise from client.method(...), so it might be the Promise from client.reload() that never gets an error handler attached to it... either way, there are two rejected promises and only one has a handler attached.

from vsphere-connect.

Yeah I like the idea of removing the dual callback promise code and just returning promises.

from vsphere-connect.

These issues have been resolved in the current alpha release

from vsphere-connect.