Issues with the NodeJS app development tools

[Shane]

Hey guys, here are a few of the issues I’ve found so far (Tested on Ubuntu 16.04 and Windows 10):

• The documentation at Home - Documentation declares the module to require as “safe”, however the actual module to require is @maidsafe/safe-node-app
• The documentation at the above URL is showing version 0.5.1, but the repository is currently up to 0.6.0, the documentation should be updated to reflect any changes.
• Using Node V7.10.0 (the required version by the package), executing the example code in the documentation throws several of these errors: DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code., requiring node to be ran with the --no-warnings argument for readable output
• When meaningful errors are thrown by the application, it’s not possible to receive them because \@maidsafe\safe-node-app\src\native\_system_uri.js on line 32 throws a reject with err instead of result. The code return reject(makeFfiError(err.error_code, err.error_description)); should be return reject(makeFfiError(result.error_code, result.error_description)); according to the declared variables within the function call.

Installing on Ubuntu

• Manually resolving this issue gets me the actual error thrown by the promise Could not execute xdg-open which seems to be a debian program for opening processes - I compiled my app with a development NODE_ENV so I should have all the dependencies (or should be told off when installing devDependencies for not having the xdg-utils package installed)
• After installing this with sudo apt-get install xdg-utils it works as expected

Installing on Windows

• I have MVS2015 C++ build tools and Python2.7 installed
• The node-gyp rebuild tool you’re using causes errors to be thrown during installation on Windows 10 in PowerShell, I got the following error before MVS2015 C++ build tools were installed: MSBUILD : error MSB4132: The tools version "2.0" is unrecognized. Available tools versions are "4.0". and the following error after it was installed: MSBUILD : error MSB4132: The tools version "2.0" is unrecognized. Available tools versions are "14.0", "4.0".
• The errors thrown during node-gyp rebuild (correctly) cause the @maidsafe/safe-node-app package to refuse to install, as such I’m unable to do any meaningful development.

[hunterlester]

Thank you for taking precious time to go through this process and for posting these points as well.

I’m adding these to our current milestones tasks.

Does xdg--utils not come installed on most Linux distributions or is this unique to Debian?

I thinking that I need to create an FAQ/Troubleshoot post or markdown document just for Windows users.

[Shane]

Some distributions have xdg-utils installed by default (as it’s one of the dependencies for the lsb repositories) but I don’t believe it comes installed by default on Debian based systems.

This wiki article has some relevant information

I’ve copied it here for the lazy:

Debian has included optional support for the LSB early on, at version 1.1 in “woody” (3.0; July 19, 2002), 2.0 in “sarge” (3.1; June 6, 2005), 3.1 in “etch” (4.0; April 8, 2007), 3.2 in “lenny” (5.0; February 14, 2009) and 4.1 in “wheezy” (7; May 4, 2013). To use foreign LSB-compliant RPM packages, the end-user needs to use Debian’s Alien program to transform them into the native package format and then install them.

The LSB-specified RPM format has a restricted subset of RPM features—to block usage of RPM features that would be untranslatable to .deb with Alien or other package conversion programs, and vice versa, as each format has capabilities the other lacks. In practice, not all Linux binary packages are necessarily LSB-compliant, so while most can be converted between .rpm and .deb, this operation is restricted to a subset of packages.

By using Alien, Debian is LSB-compatible for all intents and purposes, but according to the description of their lsb package,[18] the presence of the package “does not imply that we believe that Debian fully complies with the Linux Standard Base, and should not be construed as a statement that Debian is LSB-compliant.”[18]

Debian strived to comply with the LSB, but with many limitations.[19] However, this effort ceased around July 2015 due to lack of interest and workforce inside the project.[20] In September 2015, the Debian project confirmed that while support for Filesystem Hierarchy Standard (FHS) would continue, support for LSB had been dropped.[21] Ubuntu followed Debian in November 2015.

So it seems both Ubuntu and Debian don’t come with it pre-installed (which makes up a large portion of the desktop-linux userbase.)

Edit: This was corrected below, it’s fine in the current version of Debian, but still broke in Ubuntu

[oetyng]

I had this problem with nodejs on win10. Unfortunately I don’t remember what I did to solve it. But it was solvable after some googling.

[hunterlester]

@Shane

I got the following error before MVS2015 C++ build tools were installed

Based on this, I assumed that you solved the problem and were able to continue development.

@Shane

as such I’m unable to do any meaningful development.

Are you still hitting a wall?

[bochaco]

@Shane

So it seems both Ubuntu and Debian don’t come with it pre-installed (which makes up a large portion of the desktop-linux userbase.)

I don’t remember needing to install the xdg utilities in my Debian 8 myself, neither on a Fedora 27 I recently tried some of the apps. Are you using GNOME? which version of Debian are you using?

[Shane]

Yep, you’re correct, I run a few OSs as I’m constantly switching between them for testing and development purposes. Debian are dropping support for LSB but haven’t yet.

With that being said, on a completely fresh Ubuntu 16.04.3 LTS (Xenial) build, running lsb_release -a will result in the following:

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

So it seems as of right now, it’s only Ubuntu which isn’t natively supported, and as a result of how Linux Mint builds from Ubuntu’s previous release version, Linux Mint as well.

[Shane]

Hi there, if you’re running windows 8.1 or below, you can install MSVS2013 from here which contains MSBUILD tools version 2.0, if you’re running windows 10 or higher the following currently functions as a workaround:

Please be aware that this requires you to run your CLI as an administrator

npm install --global --production windows-build-tools

This will install MSVS C++ build tools, then run the following:

npm config set msvs_version 2015 --global or yarn config set msvs_version 2015 --global if you are using yarn instead of npm to do node_modules install command

The reason for this is that there is a bug in node-gyp, auto-detection fails for Visual C++ Build Tools 2015, so you have to force it to use it through your npm configuration.` documented here under how to use

The first time I ran the install I got errors with the weak module being unable to find a weakref.node file within bindings.js, but deleting ./node_modules and ./package-lock.json and running npm install a second time seems to have fixed whatever went wrong the first time.

After this whole process, installation works correctly and the @maidsafe package appears within ./node_modules, requests to the authenticator work as expected and safe:foo links correctly open the safe browser.

Unfortunately, however, using the mock build is still non-functional. When I compiled with $env:NODE_ENV="dev" in powershell and run the npm install, the installation is fine (after having done everything above, but running ${safe-app-library}.auth.loginForTest(perms); I get the following error:

ERROR: Error: Dynamic Symbol Retrieval Error: Win32 error 127
at DynamicLibrary.get (C:\Users\shane\Sites\SafeNet\Safe-API\node_modules\ffi\lib\dynamic_library.js:112:11)
at api.forEach (C:\Users\shane\Sites\SafeNet\Safe-API\node_modules\\@maidsafe\safe-node-app\src\native\lib.js:33:46)
at Array.forEach ()
at Object.ffi.init (C:\Users\shane\Sites\SafeNet\Safe-API\node_modules\\@maidsafe\safe-node-app\src\native\lib.js:25:9)
at new SAFEApp (C:\Users\shane\Sites\SafeNet\Safe-API\node_modules\\@maidsafe\safe-node-app\src\app.js:36:9)

To make sure it wasn’t a powershell specific issue, I re-installed the app on CMD.exe with SET NODE_ENV=dev && npm install and then SET NODE_ENV=dev && node ./path/to/my/file.js and I get the same error again, so it seems the production libraries work fine when you have Python2.7 and force MVS2015, but the mock libraries throw linking errors.

[Shane]

@hunterlester @bochaco I’ve updated my reply directly above this message with my findings, sorry for the direct ping, I’ve been at this for hours and wanted to keep it all in a single comment so it’s easy to follow.

Apologies for the number of threads, comments, etc over the past couple of days while I look in to all this, I know you guys probably have full schedules and I appreciate the time you’ve put in to replying both here and privately! The hope, though, is that if we figure out all these issues now between us and update the documentation, no one will ever encounter them again!

[hunterlester]

No worries, I’m not bothered by any of it.

We should only be thankful that people like yourself take the time and care enough to help us make the developer experience better.

Speaking for myself, I need all the help I can get. Still a new developer.

[Shane]

That’s fine - in terms of what we have discovered here, I’m still unable to get the development mock libs to link correctly, 'Im happy to have a Google hangout, Discord chat, shared terminal session, etc., with a member of your team if you think that would be something useful in getting this issue resolved.