I have a fully functioning Electron App that uses node.js fs module to look at local files. I need to compare these files to files held on Dropbox. I have the Dropbox module all set up and running and have retrieved the content-hash for each file using the filesGetMetadata method and now I need to create a hash, in the same way, for each of my local files to compare to. I have found this code here: GitHub Repo written by Dropbox themselves, but being a relative newbie to Node.js and Electron I have only ever installed and 'required' node modules. This code just requires a js file (I tried to install the module, just in case!) and despite the js file I am implementing it on existing in the same directory as dropbox-content-hasher.js (like the example in the link) I can only get the error Uncaught Error: Cannot find module './dropbox-content-hasher' in my console. I've played with a few attempts at getting the right path but the error looks like it's still looking in the node_modules folder and I've no idea how to change this. Any help appreciated?!
I worked it out through trial and error... making the assumption from all my other requires that 'it' starts by looking in the node_modules folder, the following ended up working:
require('../src/js/dropbox-content-hasher.js');
Just thought I'd update this for anyone in my situation who doesn't quite know enough before embarking on a project!!
Related
Good day,
I am using protoc to generate pb files for nodejs. This step works fine. The proto files, and the code generated from them, are kept in a central location since different services will be using them (server and clients). If I copy these files into my project and use them, everything works fine. If I try requiring the files from the central location (which is outside of my project) I get an error
Error: Cannot find module 'google-protobuf'
The core of the question is, how do I require a file from outside of my project, that in turn requires a module from my project? Can this be done? I would have imagined that once the file was requires through relative pathing, it would become a part of the project, but this doesn't appear to be the case. Please help.
I'm trying to import a file in server.js of a meteor project on Linux. For example:
var temp = require('/home/HaveAGitGat/Documents/test.js');
I get the following error:
Error: Cannot find module '/home/HaveAGitGat/Documents/test.js'
The confusing thing is this works fine on Windows using meteor. It also works fine on Linux when running pure nodejs files without meteor.
Any ideas on a resolution?
You can put your test files inside your meteor project, and it's recommended that you do so. Putting absolute paths in your code means that you are locked to that folder structure, which isn't great for portability.
For example, if you wanted me to collaborate on your project, I would have to modify all the require statements to make it work, and when I commit those changes it would break it for you.
Here's an alternative: Create a folder in imports/test to hold all your test files, so that you can import them with statements like this:
import testCase1 from '/imports/test/test1
Then your code is clean, portable, and your project is self-contained.
See https://guide.meteor.com/testing.html for more info
just like to add a short preface to this question - It may be a true issue of how Node functions, or it may be a fundamental misunderstanding on my part of how modules in Node work.
Recently, I've been working on a new project, specifically, a new Node module that requires some configuration via a .json file. I've had quite a few issues with this, being tested via linking the module to an Angular 2 (v5) project, and attempting to use the module in a service.
As I have the module set up right now, the configuration is loaded immediately as the module is initialized. It attempts to look for a config.json file, and read values from aforementioned file. I have this working, to an extent. I am able to require the file, read the file, and throw an error if the file is not found - but only in the same directory as the module's main file. The issue that I've come across is trying to determine how to find the path to the host project's root path - in this case, the Angular project. For example, say the absolute path to my module's root is /home/dev/angular2project/src/node_modules/module/. How can I determine the root path of the host, in this case /home/dev/angular2project/? What if the module has been installed globally?
I have attempted to use my weak understanding of the path module, paired with various searches of SO, to resolve this issue. I've tried using path.resolve(__dirname) to no avail path.resolve(process.cwd). This works well when debugging the module by itself. When attempted to be run from the Angular project, it simply returns / as the path, despite the actual root of the Angular project being home/dev/Desktop/angular2proj.
I started "using" Grunt.js yesterday, it seems to nest extensively deep folder structures in my projects, that look something like this:
assets\bootstrap\node_modules\grunt-contrib-jshint\node_modules\jshint\node_modules\cli\node_modules\glob\node_modules\minimatch\node_modules\brace-expansion\node_modules\balanced-match\Makefile
This still is a realtively short path, but there are loads of paths generated which my PC (running Windows 7) simply can't handle. I see this a well known issue as you can read in this Github issue of Node.js from 2014:
https://github.com/nodejs/node-v0.x-archive/issues/6960#issuecomment-46704998
However the issue still isn't fixed and a lot of people seem to be mad about it.
I wonder if I should get my head around Grunt at all because I didn't see a solid solution to get this working for me so far.
Even if I started using Mac (assumed Grunt.js works fine on mac), from my point of view Grunt seems to be a bad option if you want to be able to collaborate with people using windows.
Is there an easy way to use Gruntjs without running into file path issues on Windows?
*update: This is what GIT BASH throws at me when I am trying to track my files using git add .
warning: unable to access 'node_modules/grunt-contrib-compass/node_modules/bin-v ersion-check/node_modules/bin-version/node_modules/find-versions/node_modules/me ow/node_modules/read-pkg-up/node_modules/find-up/node_modules/pinkie-promise/nod e_modules/pinkie/.gitignore': Filename too long
Solution is to use GULP Or move your project to root directory of your drive, I am not sure if this is a grunt specific issue or rather a node specific issue
I used the command npm install firebase --save from the root of my project folder and a firebase folder was successfully added to my node_modules folder and the packages.json was also updated.
I also use typescript so I have a app.ts file where I try and do import Firebase = require("firebase");
However it doesn't work. I get red squiggles and error saying cannot find external module "firebase".
I have installed express and importing it in app.ts as well and that works fine, no errors.
I have tried to look through the firebase source but its minified and impossible to try and do any finding there, about what is exported and such.
Any ideas about what might be wrong and how I can fix it?
Three things:
You should download the Firebase type definition from Definitely Typed using NuGet, TSD, or some other method.
The Firebase definition on Definitely Typed doesn't seem to be written in an external module form. You may need to add the line export = Firebase; at the bottom of it.
TypeScript currently has odd default behavior with definition files (d.ts) that describe external modules written in JavaScript; it will search in each directory from the directory where the file is back to the root of the current drive looking for a .ts or .d.ts file with a name that matches the name of the thing you've imported. So your best bet is to move the Firebase.d.ts file to the root of the project. If you're interested in a bit more discussion on this, check out https://github.com/Microsoft/TypeScript/issues/2338 . They're working on it.
If you do those three things, it should work.