Server-side AssemblyScript: How to read a file? - server-side

I'd like to write some server-side AssemblyScript that uses the WASI interface to read a file and process the contents.
I know that AssemblyScript and the ByteCode Alliance have recently had a falling out over the "openness" of the WASI standard, but I was hoping that they would still play nicely together...
I've found several AssemblyScript tools/libraries that appear to bridge this gap, and the one that seems the simplest to use is as-wasi. After following the installation instructions, I'm just trying to run the little demo app.
All the VSCode design time errors have disappeared, but the AssemblyScript compiler still barfs at the initial import statement.
import "wasi"
import { Console, Environ } from "as-wasi/assembly";
// Create an environ instance
let env = new Environ();
// Get the HOME Environment variable
let home = env.get("HOME")!;
// Log the HOME string to stdout
Console.log(home);
Running npm run asbuild gives.
$ npm run asbuild
> file_reader#1.0.0 asbuild
> npm run asbuild:debug && npm run asbuild:release
> file_reader#1.0.0 asbuild:debug
> asc assembly/index.ts --target debug
ERROR TS6054: File '~lib/wasi.ts' not found.
:
1 │ import "wasi"
│ ~~~~~~
└─ in assembly/index.ts(1,8)
FAILURE 1 parse error(s)
The file ~lib/wasi.ts does not exist and creating this file as a softlink pointing to the index.ts in the ./node_modules/as-wasi/assembly/ directory makes no difference.
Since the library is called as-wasi and not wasi, I've tried importing as-wasi, but this also fails.
I've also tried adapting tsconfig.json to include
{
"extends": "assemblyscript/std/assembly.json",
"include": [
"../node_modules/as-wasi/assembly/*.ts",
"./**/*.ts"
]
}
But this also has no effect.
What is causing asc to think that the required library should be in the directory called ~lib/ and how should I point it to the correct place?
Thanks

Your question threw me in a bit of a rabbit hole, but I think I solved it.
So, apparently, after the wasi schism, AssemblyScript added the wasi-shim repository, that you have to install as well:
npm install --save wasi-shim
The import "wasi" is no longer necessary after version 0.20 of AssemblyScript according to the same page, so you have to remove that import entirely. Also, be sure to add the extends to your asconfig.json, as recommended in the same wasi-shim page. Mine looks like this:
{
"extends": "./node_modules/#assemblyscript/wasi-shim/asconfig.json",
"targets": {
"debug": {
"outFile": "build/debug.wasm",
"textFile": "build/debug.wat",
"sourceMap": true,
"debug": true
},
"release": {
"outFile": "build/release.wasm",
"textFile": "build/release.wat",
"sourceMap": true,
"optimizeLevel": 3,
"shrinkLevel": 0,
"converge": false,
"noAssert": false
}
},
"options": {
"bindings": "esm"
}
}
It is just the generated original asconfig.json plus that extends.
Now the things got interesting. I got a compilation error:
ERROR TS2300: Duplicate identifier 'wasi_abort'.
:
1100 │ export function wasi_abort(
│ ~~~~~~~~~~
└─ in ~lib/as-wasi/assembly/as-wasi.ts(1100,17)
:
19 │ export function wasi_abort(
│ ~~~~~~~~~~
└─ in ~lib/wasi_internal.ts(19,17)
So I investigated, and it seems that as-wasi was exporting a symbol that was the same as a symbol exported by wasi_shim. No biggie, I went into node_modules/as-wasi/, and I renamed that function into as_wasi_abort. I did this also with the invokations of the function, namely three instances found in the package.json from as-wasi:
{
"asbuild:untouched": "asc assembly/index.ts -b build/untouched.wasm -t build/untouched.wat --use abort=as_wasi_abort --debug",
"asbuild:small": "asc assembly/index.ts -b build/optimized.wasm -t build/optimized.wat --use abort=as_wasi_abort -O3z ",
"asbuild:optimized": "asc assembly/index.ts -b build/optimized.wasm -t build/optimized.wat --use abort=as_wasi_abort -O3",
}
Having done all this, the package compiled and the example from Wasm By Example finally worked.
Your code should compile now, and I will try to make a pull request to all the places necessary so that the examples are updated, the code in as-wasi is updated, and so that nobody has to go through this again. Please comment if there are further problems.
Edit: It seems that I was right about the wasi_abort function being a problem. It is actually removed on the as-wasi repo, but the npm package is outdated. I asked in my pull request for it to be updated.

Related

How do I deploy monorepo code to AWS Lambda using lerna?

I am attempting to make two AWS Lambda functions (written in typescript). Both of these functions share the same code for interacting with an API. In order to not have to copy the same code to two different Lambdas, I would like to move my shared code to a local module, and have both my Lambdas depend on said module.
My initial attempt at staring code between the two lambdas was to use a monorepo and lerna. My current project structure looks like this:
- lerna.json
- package.json
- packages
- api
- package.json
- lambdas
- funcA
- package.json
- func B
- package.json
lerna.json:
{
"packages": [
"packages/api",
"packages/lambdas/*"
],
"version": "1.0.0"
}
In each of my package.json for my Lambda functions, I am able to include my local api module as such:
"dependencies": {
"#local/api": "*"
}
With this, I've been able to move the common code to its own module. However, I'm now not sure how to bundle my functions to deploy to AWS Lambda. Is there a way for lerna to be able to create a bundle that can be deployed?
As cp -rL doesn't work on the mac I had to come up with something similar.
Here is a workflow that works if all of your packages belong to one scope (#org):
In the package.json of your lerna repo:
"scripts": {
"deploy": "lerna exec \"rm -rf node_modules\" && lerna bootstrap -- --production && lerna run deploy && lerna bootstrap"
}
In the package that contains your lambda function:
"scripts":{
"deploy": "npm pack && tar zxvf packagename-version.tgz && rm -rf node_modules/#org && cp -r node_modules/* package/node_modules && cd package && npm dedupe"
}
Now replace "packagename-version" and "#org" with the respective values of your project. Also add all of the dependent packages to "bundledDependencies".
After running npm run deploy in the root of your lerna mono repo you end up with a folder "package" in the package that contains your lambda function. It has all the dependencies needed to run your function. Take it from there.
I had hoped that using npm pack would allow me to utilize .npmignore files but it seems that that doesn't work. If anyone has an idea how to make it work let me know.
I have struggled with this same problem for a while now, and I was finally forced to do something about it.
I was using a little package named slice-node-modules, as found here in this similar question, which was good enough for my purposes for a while. As I have consolidated more of my projects into monorepos and begun using shared dependencies which reside as siblings rather than being externally published, I ran into shortcomings with that approach.
I've created a new tool called lerna-to-lambda which was specifically tailored to my use case. I published it publicly with minimal documentation, hopefully enough to help others in similar situations. The gist of it is that you run l2l in your bundling step, after you've installed all of your dependencies, and it copies what is needed into an output directory which is then ready to deploy to Lambda using SAM or whatever.
For example, from the README, something like this might be in your Lambda function's package.json:
"scripts": {
...
"clean": "rimraf build lambda",
"compile": "tsc -p tsconfig.build.json",
"package": "l2l -i build -o lambda",
"build": "yarn run clean && yarn run compile && yarn run package"
},
In this case, the compile step is compiling TypeScript files from a source directory into JavaScript files in the build directory. Then the package step bundles up all the code from build along with all of the Lambda's dependencies (except aws-sdk) into the directory lambda, which is what you'd deploy to AWS. If someone were using plain JavaScript rather than TypeScript, they could just copy the necessary .js files into the build directory before packaging.
I realize this question is over 2 years old, and you've probably figured out your own solutions and/or workarounds since then. But since it is still relevant to me, I assume it's still relevant to someone out there, so I am sharing.
Running lerna bootstrap will create a node_modules folder in each "package". This will include all of your lerna managed dependencies as well as external dependencies for that particular package.
From then on, your deployment of each lambda will be agnostic of the fact that you're using lerna. The deployment package will need to include the code for that specific lambda and the node_modules folder for that lambda - you can zip these and upload them manually, or use something like SAM or CloudFormation.
Edit: as you rightly point out you'll end up with symlinks in your node_modules folder which make things awkward to package up. To get around this, you could run something like this prior to packaging for deployment:
cp -rL lambdas/funcA/node_modules lambdas/funcA/packaged/node_modules
The -L will force the symlinked directories to be copied into the folder, which you can then zip.
I have used a custom script to copy the dependencies during the install process.. This will allow me to develop and deploy the application with the same code.
Project structure
In the package.json file of the lambda_a, I have the following line:
"scripts": {
"install": "node ./install_libs.js #libs/library_a"
},
#libs/library_a can be used by the lambda code using the following statement:
const library_a = require('#libs/library_a')
for SAM builds, I use the following command from the lmbdas frolder:
export SAM_BUILD=true && sam build
install_libs.js
console.log("Starting module installation")
var fs = require('fs');
var path = require('path');
var {exec} = require("child_process");
if (!fs.existsSync("node_modules")) {
fs.mkdirSync("node_modules");
}
if (!fs.existsSync("node_modules/#libs")) {
fs.mkdirSync("node_modules/#libs");
}
const sam_build = process.env.SAM_BUILD || false
libs_path = "../../"
if (sam_build) {
libs_path = "../../" + libs_path
}
process.argv.forEach(async function (val, index, array) {
if (index > 1) {
var currentLib = libs_path + val
console.log(`Building lib ${currentLib}`)
await exec(`cd ${currentLib} && npm install` , function (error, stdout, stderr){
if (error) {
console.log(`error: ${error.message}`);
return;
}
console.log(`stdout: ${stdout}`);
console.log('Importing module : ' + currentLib);
copyFolderRecursiveSync(currentLib, "node_modules/#libs")
});
}
});
function copyFolderRecursiveSync(source, target) {
var files = [];
// Check if folder needs to be created or integrated
var targetFolder = path.join(target, path.basename(source));
if (!fs.existsSync(targetFolder)) {
fs.mkdirSync(targetFolder);
}
// Copy
if (fs.lstatSync(source).isDirectory()) {
files = fs.readdirSync(source);
files.forEach(function (file) {
var curSource = path.join(source, file);
if (fs.lstatSync(curSource).isDirectory()) {
copyFolderRecursiveSync(curSource, targetFolder);
} else {
copyFileSync(curSource, targetFolder);
}
});
}
}
function copyFileSync(source, target) {
var targetFile = target;
// If target is a directory, a new file with the same name will be created
if (fs.existsSync(target)) {
if (fs.lstatSync(target).isDirectory()) {
targetFile = path.join(target, path.basename(source));
}
}
fs.writeFileSync(targetFile, fs.readFileSync(source));
}

Change Ember build directory (dist folder) without command line flags

I am trying to make my Ember project build to a directory outside of the project and for future builds I don't want to use command line flags each time.
ember build --output-path=/not-dist will work for me but I want Ember to add the flag automatically.
outputPaths: {
app: {
html: '../presentation/index.cfm',
css: {
'app': '../presentation/assets/ember-presentation-viewer.css'
},
js: '../presentation/assets/ember-presentation-viewer.js'
},
vendor: {
css: '../presentation/assets/vendor.css',
js: '../presentation/assets/vendor.js'
}
}
I have tried this as per the ember-cli documentation but ember-presentation-viewer.css was insisting on getting built in the dist directory with all the additional paths put there.
Is there a way to do this?
Go to package.json. Change scripts/build command:
"scripts": {
"build": "ember build --output-path=/not-dist"
},
From now on, run:
npm run build
You can configure your .ember-cli.js file to specify flags that should always be included in your command line builds (in lower camel case), as per this page in the Ember docs. To change the output directory you'll want to add the following line: "outputPath": "../../example-folder/presentation".
So your final .ember-cli.js should look like this:
{
/*
Ember CLI sends analytics information by default. The data is completely
anonymous, but there are times when you might want to disable this behavior.
Setting `disableAnalytics` to true will prevent any data from being sent.
*/
"disableAnalytics": false,
"outputPath": "../../example-folder/presentation"
}

How can I call Django's manage.py from GNOME Builder?

I have GNOME Builder installed on 3.24.1 installed on Ubuntu 17.04. I have a functional Django project and an associated virtualenv. (Django 1.11, Python 3)
How can I configure Builder, so that when I click Run it invokes manage.py runserver in the virtualenv? (Ideally I'd like to be able to run other manage.py functions too, like manage.py collectstatic.)
This is not really possible as Gnome-Builder works tightly integrated with flatpak. As far as I know the "hostsystem buildsystem" only supports auto detected run targets and only one of those.
However if you create a flatpak json manifest you can set the command to be run in the command variable of the json manifest - though probably not everything you want. As this means the application runs in a flatpak sandbox.
Setup
To do that you can create a new python gnome application with gnome-builder called djangoproj. This will generate a Project that uses the meson buildsystem and a org.gnome.djangoproj.json. The next thing would be to remove the gnome application - or you just ignore it and add your Django dependencies.
Add the required modules before the native modules. For just Django this is:
[…]
"modules" : [
{
"name": "python3-Django",
"buildsystem": "simple",
"build-commands": [
"pip3 install --no-index --find-links=\"file://${PWD}\" --prefix=${FLATPAK_DEST} Django"
],
"sources": [
{
"type": "file",
"url": "https://pypi.python.org/packages/1b/50/4cdc62fc0753595fc16c8f722a89740f487c6e5670c644eb8983946777be/pytz-2018.3.tar.gz",
"sha256": "410bcd1d6409026fbaa65d9ed33bf6dd8b1e94a499e32168acfc7b332e4095c0"
},
{
"type": "file",
"url": "https://pypi.python.org/packages/54/59/4987ae4a4a8be8507af1b213e75a449c05939ab1e0f62b5e90ccea2b51c3/Django-2.0.3.tar.gz",
"sha256": "769f212ffd5762f72c764fa648fca3b7f7dd4ec27407198b68e7c4abf4609fd0"
}
]
},
{
"name" : "djangoproj",
"buildsystem" : "meson",
[…]
If you have additional dependencies there is a handy tool to generate the necessary json lines: https://github.com/flatpak/flatpak-builder-tools/tree/master/pip
Now you can add the Django project files using the host system.
django-admin startproject sample
Meson needs to know about the new files so just add subdir('sample') to the root meson directory and create new meson files in the subdirectories. The meson.build in the sample directory looks like this for me. for the sample/sample directory you'd need to adjust the moduledir and the djangoproj_sources
pkgdatadir = join_paths(get_option('prefix'), get_option('datadir'), meson.project_name())
moduledir = join_paths(pkgdatadir, 'djangoproj')
python3 = import('python3')
conf = configuration_data()
conf.set('PYTHON', python3.find_python().path())
conf.set('VERSION', meson.project_version())
conf.set('localedir', join_paths(get_option('prefix'), get_option('localedir')))
conf.set('pkgdatadir', pkgdatadir)
subdir('sample')
djangoproj_sources = [
'manage.py',
]
install_data(djangoproj_sources, install_dir: moduledir)
Now you can set the command in the org.gnome.Djangoproj.json to bash and after pressing launch in the window where otherwise the logs of the program appear there is an interactive shell. There you can explore your newly created flatpak with Django included in the /app/ directory. If you want to run the Django app you'd do:
$ python3 /app/share/djangoproj2/djangoproj2/manage.py runserver
you can also write this command in the command variable of the json file to launch it directly when pressing the "play"-button.
All the other commands do work too- however keep in mind that the environment is in a flatpak and recreated on every rebuild... So nothing that needs to persist can be saved in the flatpak directory.

Angular 2 Unit Tests: Cannot find name 'describe'

I'm following this tutorial from angular.io
As they said, I've created hero.spec.ts file to create unit tests:
import { Hero } from './hero';
describe('Hero', () => {
it('has name', () => {
let hero: Hero = {id: 1, name: 'Super Cat'};
expect(hero.name).toEqual('Super Cat');
});
it('has id', () => {
let hero: Hero = {id: 1, name: 'Super Cat'};
expect(hero.id).toEqual(1);
});
});
Unit Tests work like a charm. The problem is: I see some errors, which are mentioned in tutorial:
Our editor and the compiler may complain that they don’t know what it
and expect are because they lack the typing files that describe
Jasmine. We can ignore those annoying complaints for now as they are
harmless.
And they indeed ignored it. Even though those errors are harmless, it doesn't look good in my output console when I receive bunch of them.
Example of what I get:
Cannot find name 'describe'.
Cannot find name 'it'.
Cannot find name 'expect'.
What can I do to fix it?
I hope you've installed -
npm install --save-dev #types/jasmine
Then put following import at the top of the hero.spec.ts file -
import 'jasmine';
It should solve the problem.
With Typescript#2.0 or later you can install types with:
npm install -D #types/jasmine
Then import the types automatically using the types option in tsconfig.json:
"types": ["jasmine"],
This solution does not require import {} from 'jasmine'; in each spec file.
npm install #types/jasmine
As mentioned in some comments the "types": ["jasmine"] is not needed anymore, all #types packages are automatically included in compilation (since v2.1 I think).
In my opinion the easiest solution is to exclude the test files in your tsconfig.json like:
"exclude": [
"node_modules",
"**/*.spec.ts"
]
This works for me.
Further information in the official tsconfig docs.
You need to install typings for jasmine. Assuming you are on a relatively recent version of typescript 2 you should be able to do:
npm install --save-dev #types/jasmine
With Typescript#2.0 or later you can install types with npm install
npm install --save-dev #types/jasmine
then import the types automatically using the typeRoots option in tsconfig.json.
"typeRoots": [
"node_modules/#types"
],
This solution does not require import {} from 'jasmine'; in each spec file.
In order for TypeScript Compiler to use all visible Type Definitions during compilation, types option should be removed completely from compilerOptions field in tsconfig.json file.
This problem arises when there exists some types entries in compilerOptions field, where at the same time jest entry is missing.
So in order to fix the problem, compilerOptions field in your tscongfig.json should either include jest in types area or get rid of types comnpletely:
{
"compilerOptions": {
"esModuleInterop": true,
"target": "es6",
"module": "commonjs",
"outDir": "dist",
"types": ["reflect-metadata", "jest"], //<-- add jest or remove completely
"moduleResolution": "node",
"sourceMap": true
},
"include": [
"src/**/*.ts"
],
"exclude": [
"node_modules"
]
}
Solution to this problem is connected with what #Pace has written in his answer. However, it doesn't explain everything so, if you don't mind, I'll write it by myself.
SOLUTION:
Adding this line:
///<reference path="./../../../typings/globals/jasmine/index.d.ts"/>
at the beginning of hero.spec.ts file fixes problem. Path leads to typings folder (where all typings are stored).
To install typings you need to create typings.json file in root of your project with following content:
{
"globalDependencies": {
"core-js": "registry:dt/core-js#0.0.0+20160602141332",
"jasmine": "registry:dt/jasmine#2.2.0+20160621224255",
"node": "registry:dt/node#6.0.0+20160807145350"
}
}
And run typings install (where typings is NPM package).
In my case, the solution was to remove the typeRoots in my tsconfig.json.
As you can read in the TypeScript doc
If typeRoots is specified, only packages under typeRoots will be included.
I'm up to the latest as of today and found the best way to resolve this is to do nothing...no typeRoots no types no exclude no include all the defaults seem to be working just fine. Actually it didn't work right for me until I removed them all. I had:
"exclude": [
"node_modules"
]
but that's in the defaults so I removed that.
I had:
"types": [
"node"
]
to get past some compiler warning. But now I removed that too.
The warning that shouldn't be is:
error TS2304: Cannot find name 'AsyncIterable'.
from node_modules\#types\graphql\subscription\subscribe.d.ts
which is very obnoxious so I did this in tsconfig so that it loads it:
"compilerOptions": {
"target": "esnext",
}
since it's in the esnext set. I'm not using it directly so no worries here about compatibility just yet. Hope that doesn't burn me later.
I'll just add Answer for what works for me in "typescript": "3.2.4" I realized that jasmine in node_modules/#types there is a folder for ts3.1 under the jasmine type so here are the steps:-
Install type jasmine npm install -D #types/jasmine
Add to tsconfig.json jasmine/ts3.1
"typeRoots": [
...
"./node_modules/jasmine/ts3.1"
],
Add Jasmine to the types
"types": [
"jasmine",
"node"
],
Note: No need for this import 'jasmine'; anymore.
Only had to do the following to pick up #types in a Lerna Mono-repo
where several node_modules exist.
npm install -D #types/jasmine
Then in each tsconfig.file of each module or app
"typeRoots": [
"node_modules/#types",
"../../node_modules/#types" <-- I added this line
],
In my case, I was getting this error when I serve the app, not when testing. I didn't realise I had a different configuration setting in my tsconfig.app.json file.
I previously had this:
{
...
"include": [
"src/**/*.ts"
]
}
It was including all my .spec.ts files when serving the app. I changed the include property toexclude` and added a regex to exclude all test files like this:
{
...
"exclude": [
"**/*.spec.ts",
"**/__mocks__"
]
}
Now it works as expected.
I had this error in an angular library. Turns out I accidentally included my .spec file in the exports in my public-api.ts. Removing the export fixed my issue.
Look at the import maybe you have a cycle dependency, this was in my case the error, using import {} from 'jasmine'; will fix the errors in the console and make the code compilable but not removes the root of devil (in my case the cycle dependency).
I'm on Angular 6, Typescript 2.7, and I'm using Jest framework to unit test.
I had #types/jest installed and added on typeRoots inside tsconfig.json
But still have the display error below (i.e: on terminal there is no errors)
cannot find name describe
And adding the import :
import {} from 'jest'; // in my case or jasmine if you're using jasmine
doesn't technically do anything, so I thought, that there is an import somewhere causing this problem, then I found, that if delete the file
tsconfig.spec.json
in the src/ folder, solved the problem for me. As #types is imported before inside the rootTypes.
I recommend you to do same and delete this file, no needed config is inside. (ps: if you're in the same case as I am)
If the error is in the .specs file
app/app.component.spec.ts(7,3): error TS2304: Cannot find name 'beforeEach'.
add this to the top of your file and npm install rxjs
import { range } from 'rxjs';
import { map, filter } from 'rxjs/operators';
Just add to your tsconfig.json, and be sure that you don't have "**/*.spec.ts"
in exclude
"include": [
"src/**/*.spec.ts",
"src/**/*.d.ts"
]
My working tsconfig.json

Installing node-gd on windows

In the past few hours I'm trying to run node-gd on windows. I've tried several repos and finally found https://github.com/mikesmullin/node-gd. When I run
`npm install node-gd`
I'm getting the following error:
node-gyp rebuild
...node_modules\node-gd>node "C:\Program Files\nodejs\node_modules\npm\
bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild
Building the projects in this solution one at a time. To enable parallel build,
please add the "/m" switch.
node-gd.cpp
..\cpp\node-gd.cpp(17): fatal error C1083: Cannot open include file: 'gd.h': No
such file or directory [...\node_modules\node-gd\build\node_gd.vcxproj
]
I thought I should install gd lib, but when I googled it, almost all information is about php_gd not about the lib itself.
Where should I put the gd files?
Edit: I compiled it! Now I'm getting:
I went through this process recently and encountered the same issues, but wasn't able to find any posted steps for resolving the problems. I realize this thread is nearly 1.5 years old now, but I'll post my complete installation steps here on the chance it'll help someone else.
This assumes you already have the GD library built (https://github.com/libgd/libgd/releases), and will be using the GD DLL.
Download the node-gd package from https://www.npmjs.com/package/node-gd
Note: Don't run "npm install node-gd" from a prompt, as this will automatically download and run the install. You need to make some local changes to the package first, then install it locally.
After extraction, open the binding.gyp file, e.g. located at (downloads_folder)\node-gd\binding.gyp
Change this line:
"libraries": ["-lgd"],
to the name of the GD DLL import library that was compiled, e.g. for "libgd.lib":
"libraries": ["-llibgd"],
Add the GD source path to "include_dirs", e.g.:
"include_dirs": [
"<!(node -e \"require('nan')\")",
"(path_to_gd)/src" # <-- THIS ENTRY
],
Add the GD compiled library directory to the VS linker settings under the "conditions" field for windows, e.g.:
Note: For some reason I couldn't get the library directory to work correctly via gyp's conventional binding specifications, so I had to resort to this...
"conditions": [
[ "OS=='freebsd'", {
"libraries": ["-L/usr/local/lib"],
"include_dirs": ["/usr/local/include"]
}],
[ "OS=='mac'", {
"libraries": ["-L/usr/local/lib", "-L/opt/local/lib"],
"include_dirs": ["/usr/local/include", "/opt/local/include"]
}],
[ "OS=='win'", { # <-- THIS ENTRY
"msvs_settings": {
"VCLinkerTool": {
"AdditionalOptions": ["/LIBPATH:(path_to_gd)/build_msvc12_x64"],
},
},
}],
]
Save the binding.gyp file, and install the package locally, e.g.:
npm install (downloads_folder)\node-gd
If you try to use node-gd at this point (via require) you'll get the "module could not be found" error the OP was getting above. The problem isn't that the module can't be found, it's that it can't find the GD DLL (the error message is terrible). So, copy the GD .dll file to the node-gd output directory (it needs to be next to the node-gd binary files that were just built), e.g.:
copy (path_to_gd)\build_msvc12_x64\libgd.dll (path_to_node_modules)\node-gd\build\Release\libgd.dll
That should be it! Hopefully everything works at this point.