I know that this must be a really basic problem, but I've never really learned what to do with node modules after you npm -i them. Every time I try to reference a js or css file in node modules, I get a 404 error, so I've been moving the needed src files into my static folder and importing/using them from there.
Problem is, now I've run into a complex enough package, that this (hacky?) solution doesn't work, the files relatively reference each other a LOT and I would have to go in and update all the references. Not to mention, even if I do change all the references, I also have to add the file extensions, because it doesn't seem to find them automatically, even for .js files, which I'm not sure I understand.
Also this solution leaves me with a folder structure like
node_modeules
--> package
----> src
------>js
--------> file.js
public
--> javascripts
---->file.js
which feels like a poor use of disk space, since I'm doubling up on files.
So my question is, how should I be importing node_module packages and using them?
Related
I'm trying to avoid relative require() calls in my express setup. I'd also like to avoid placing my code in the node_modules folder. In short, I'm trying to implement any of the methods described in this gist.
Any of those solutions will work fine for executing code with node or npm. However, I'm trying to find a solution that will also be supported by Intellij IDEA's code resolver, i.e. trying to make sure "go to declaration" and autocomplete hinting works.
I've tried the following
Setting NODE_PATH in the run configuration.
Using a global prefix, i.e. require( global.__base + "mylib").
Adding a symlinked folder to node_modules/.
Adding a symlink from a lib/ folder to node_modules/lib/ does work, but comes with two caveats:
Changes to the source files aren't picked up automatically, so I have to manually "synchronize" node_modules/lib, and
When "going to declaration", IntelliJ (of course) opens node_modules/lib/mylib instead of lib/mylib. This can lead to confusion as the actual file and the symlinked file can be open in separate windows.
Instead of a different way to require local paths (all these methods do work with node after all), I'd be happy with a way to hint to IDEA that it should search the lib/ folder for sources.
So, I realised that if you add a library through Project Structure > Libraries, it won't actually be enabled.
Instead, go to Preferences > Languages & Frameworks > Javascript > Libraries and add a new library. Set the framework type to node_modules, Visibility to Project and add your lib folder.
After adding it, make sure the Enabled checkbox is checked.
That's it, Intellij can now resolve your require('mylib') paths.
Use whatever method from the gist mentioned in the question to actually get node to resolve the paths.
I'm wondering if there is a way with node to make a directory a containing package, like __init__.py does it in python?
If your package is in a directory named "node_modules", and that directory is locatable somewhere shallower in the filesystem tree that the requiring module, require will find it. So you could do:
myapp.js
node_modules/mylib/package.json
node_modules/mylib/index.js
and myapp.js could just require("mylib"). This also works if that node_modules directory is anywhere shallower in the fs.
That's the simple solution but it isn't commonly done because most people want to .gitignore their node_modules directory and only put transient third party stuff in there.
This problem is extensively and exhaustively discussed in the gist better local require paths. I recommend reading through that for other approaches. Ultimately I think things end up as totally separate projects packaged as separate modules, so move toward that end state as soon as it is justified.
Working on the new android side of extensions with the changes. I have my separate extension as its own dependency.
In my code I require references to the Extension.Java class as well as the HaxeObject.
These are located in extensions-api, which is it's own separate dependency.
I've tried including these files in my own dependency, this causes top-level exceptions because a number of the Java files were included twice. I've also tried not including the extensions-api, this works to some extent, however If in the future I decide to use more extensions this won't work (less than ideal).
I need to find a way to reference these files from one dependency to another. so from: MyExtension.src.org.haxe.nme.MyExtension and extension-api.src.org.haxe.nme.Extension
So I guess the point I'm stuck at is how I make these two dependencies see each other whilst compiling so that when they merge to make the .dex file they don't cause top-level exceptions.
I could potentially hack it by placing my extension into the extension-api folder. Something like:
<dependency name="extension-api" path="dependencies/MyExtension" if="android"/>
The issue with this being that the androidManifest merging wouldn't work.
I found the answer here:
the gist is in the project.properties file you want to add the line:
android.library.reference.1=../extensions-api
http://www.openfl.org/community/general-discussion/native-extensions/
I think it would be great to directly import modules from node_modules directory without need to manually provide a declaration file for it (let us assume that declaration is provided with module itself). I guess that problem are dependencies that come with declarations (file paths could be resolved relative to the module, but that would cause duplicates and compiler can't handle that).
Currently working with node modules is very inconvenient because simple install from npm repository just isn't enough and we have to manually search for declarations and provide them in our project. Let's say that our project is dependent on 10 node modules (all of them have declarations) and after a year we would like to update them. We would have to manually search for new declarations and let's say that we have around 20 projects like this (it would become a nightmare). Maybe there should be an option to directly import .ts file from node module?
Do you have any suggestions?
This is a re-post from CodePlex to hear your opinions ...
If you use grunt-typescript then I've got a pull request which solves this at least for me. See https://github.com/k-maru/grunt-typescript/pull/36
From the pull request README
Working with modules in node_modules (i.e. npm)
The standard way to use npm packages is to provide a definition file
that specifies the package to the typescript and import the module from there.
///<reference path="path/to/mod.d.ts" />
import mod = module('mod')
The typescript compiler will convert the import to a nodejs require.
var mod = require('mod')
This is pretty unwieldy as you need to know the precise path to the
npm installed package and npm can put the package at pretty much any
level when you are working with multiple levels of dependencies.
With the node_modules option in the grunt config you can just
import a npm package without need to know the exact level where the
package has been installed by npm as long as it is installed locally
and not globally.
To import an npm module in your typescript source do
import npmModule = module('node_modules/npmModule/foo')
Mostly due to a lucky chance this works. Typescript compiler will read
the typescript definition file node_modules/npmModule/foo.d.ts if it
is present at some point on the way towards the root and the resulting
javascript file will contain a require for npmModule/foo if needed.
I don't think that node modules will ever contain built-in typescript support. The language still is a 0.x release and officially described as an alpha version.
Nevertheless there are means to ease the configuration process for typescript. Github already contains huge collections of .d.ts files such as:
https://github.com/borisyankov/DefinitelyTyped
or
https://github.com/soywiz/typescript-node-definitions
You might want to take a look at this tool: https://github.com/Diullei/tsd .
I've never used it but it seems like it's almost what you're looking for.
Moreover I've heard that an official database of .d.ts files is planned. Unfortunately I couldn't find the link but it will probably be some time before this is implemented anyways.
I'm working on a large Node project. Naturally, I want to break this into multiple source files. There are many modules from the standard lib that I use in a majority of my source files, and there are also quite a few of my own files that I want to use almost everywhere.
I've been making this work by including a huge require block at the beginning of each source file, but this feels awfully redundant. Is there a better way to do this? Or is this an intended consequence of Node's admirable module system?
You can use a container module to load a series of modules. For example, given the following project structure:
lib/
index.js
module1.js
module2.js
main.js
You can have index.js import the other modules in the library.
# index.js
module.exports.module1 = require('./module1');
module.exports.module2 = require('./module2');
Then main.js need only import a single module:
# main.js
var lib = require('./lib');
lib.module1.doSomething();
lib.module2.doSomethingElse();
This technique can be expanded, reducing redundant imports.
I'd say generally that a require block is better practice than using global in Node.
You need to remember that requires are cached so when you put them in all of your code modules, you will always get the same instance not a new one each time.
Doing it this way ensures that you get the appropriate code with the expected name spaces exactly where you want it whereas using global will include things you don't need. Doing it the Node way with require will also tend to make your code slightly more portable.
Well, a couple of things, here.
First, if so many of your files are requiring the same libraries over and over again, you might want to step back and determine if you're really breaking your code up in the proper way. Perhaps there's a better organization where certain libraries are only needed by subsets of your source files?
Second, remember that the global object is shared between all of your required files in your Node.js app. Your "root" source file, say index.js, can do things like global.fs = require('fs'); and then it's accessible from all of your various files. This would eliminate the need to require a file full of requires. (In Node.js, you have to explicitly state that you're accessing a global variable by prepending global., unlike in the browser.)
This can be a good idea for CRUD-type Express apps where you have lots of code for controllers that are all almost the same but have to be slightly different for each view and you just want to split them apart not for any particular organization structure, but just to make it easier to debug (error in this file, not that file). If the structure of the app is more complex than that, take the usual warnings against global variables to heart before using that trick.
Require more than one file without absolute path through require-file-directory.
1- Can require more than one file in single statement.
2- Can require files with only their name.
Visit for solution: https://www.npmjs.com/package/require-file-directory