Comment faire de l'exiger dans node.js toujours par rapport à la racine du dossier du projet?

Question

Je tiens à besoin de mes fichiers toujours par la racine de mon projet et non pas par rapport à ce module.

Par exemple, si vous regardez https://github.com/visionmedia/express/blob/2820f2227de0229c5d7f28009aa432f9f3a7b5f9/examples/downloads/app.js ligne 6, vous verrez

express = require('../../')

C'est vraiment mauvais de l'OMI. Imaginez que je voudrais mettre tous mes exemples plus proche de la racine par un seul niveau. Ce serait impossible, parce que j'aurais à mettre à jour plus de 30 exemples et de nombreuses fois à l'intérieur de chaque exemple. Pour cela:

express = require('../')

Ma solution serait d'avoir un cas spécial pour racine: si une chaîne commence par un $, puis il est relatif à la racine du dossier du projet.

Toute aide est appréciée, merci

Mise à jour 2

Maintenant, je suis en utilisant require.js qui permet d'écrire dans un sens et travaille à la fois sur le client et sur le serveur. Require.js vous permet également de créer des chemins d'accès personnalisés.

Answer 1

Et que dire de:

var myModule = require.main.require( './path/to/module' ) ;

Il nécessite le fichier comme si c'était nécessaire de le principal fichier js, de sorte qu'il fonctionne assez bien en tant que votre principale js fichier est à la racine de votre projet... et c'est quelque chose que j'apprécie.

Answer 2

Il y a un très intéressant article dans le Browserify Manuel:

en évitant ../../../../../../..

Pas tout dans une application correctement appartient sur le public npm et la surcharge de la configuration d'un privé mnp ou repo git est encore plutôt grand, dans de nombreux cas. Ici sont quelques approches pour éviter les ../../../../../../../ par rapport chemins de problème.

node_modules

Parfois, les gens de l'objet à mettre l'application des modules spécifiques en node_modules car il n'est pas évident pour vous de vérifier dans votre intérieur les modules sans vérifie aussi dans les modules tiers de mnp.

La réponse est assez simple! Si vous avez un .gitignore fichier ignore node_modules:

node_modules

Vous pouvez simplement ajouter une exception avec ! pour chacun de vos internes des modules de l'application:

node_modules/*
!node_modules/foo
!node_modules/bar

Veuillez noter que vous ne pouvez pas ne plus ignorer un sous-répertoire, si le parent est déjà ignoré. Donc, au lieu de l'ignorer node_modules, vous avez pour ignorer tous les répertoires à l'intérieur d' node_modules avec le node_modules/* truc, et puis vous pouvez ajouter vos exceptions.

Maintenant, n'importe où dans votre application, vous serez en mesure d' require('foo') ou require('bar') sans avoir un très grand et fragile par rapport chemin d'accès.

Si vous avez beaucoup de modules et de les tenir au plus distincte de le tiers des modules installés par npm, il vous suffit de les mettre tous en vertu d'un répertoire dans le répertoire node_modules comme node_modules/app:

node_modules/app/foo
node_modules/app/bar

Maintenant, vous serez en mesure d' require('app/foo') ou require('app/bar') à partir de n'importe où dans votre application.

Dans votre .gitignore, il suffit d'ajouter une exception pour node_modules/app:

node_modules/*
!node_modules/app

Si votre application a transforme configuré dans le paquet.json, vous aurez besoin de créer un paquet séparé.json avec ses propres transformer le terrain en votre node_modules/foo ou node_modules/app/foo répertoire composant parce que les transformations ne s'appliquent pas à travers le module de limites. Ce sera faire vos modules plus robuste contre les modifications de la configuration de votre application et il sera plus facile à indépendamment de réutiliser les paquets en dehors de votre application.

lien symbolique

Un autre truc utile si vous travaillez sur une application où vous pouvez faire des liens symboliques et n'ont pas besoin de support de windows est un lien symbolique lib/ ou app/ le dossier en node_modules. À partir de la racine du projet, faire:

ln -s ../lib node_modules/app

et maintenant, à partir de n'importe où dans votre projet, vous serez en mesure d'exiger des fichiers en lib/ en effectuant require('app/foo.js') pour obtenir de l' lib/foo.js.

des chemins d'accès personnalisés

Vous pouvez voir quelques endroits en parler à l'aide de l' $NODE_PATH la variable d'environnement ou d' opts.paths d'ajouter des répertoires pour le nœud et browserify à regarder dans pour trouver les modules.

Contrairement à la plupart des autres plates-formes, à l'aide d'une coquille de style de tableau de chemin les répertoires avec des $NODE_PATH n'est pas aussi favorable dans le nœud par rapport à l'utilisation efficace de l' node_modules répertoire.

C'est parce que votre application est plus étroitement couplé à un moteur d'exécution configuration de l'environnement il y a donc plus de pièces mobiles et de votre l'application ne fonctionne que lorsque votre environnement est configuré correctement.

nœud et browserify à la fois de support, mais de décourager l'utilisation de $NODE_PATH.

Answer 3

Je tiens à faire un nouveau node_modules le dossier pour le partage de code, puis laissez-le nœud et nécessitent de faire ce qu'il fait de mieux.

par exemple:

- node_modules // => these are loaded from your package.json
- app
  - node_modules // => add node-style modules
    - helper.js
  - models
    - user
    - car
- package.json
- .gitignore

Par exemple, si vous êtes en car/index.js vous pouvez require('helper') et nœud à le trouver!

Comment node_modules Travail

nœud a un algorithme intelligent pour résoudre les modules qui est unique parmi les rivaux les plates-formes.

Si vous require('./foo.js') de /beep/boop/bar.js, nœud cherchera ./foo.js en /beep/boop/foo.js. Les chemins qui commencent par un ./ ou ../ sont toujours locales pour le fichier qui appelle require().

Si toutefois vous avez besoin d'un non-parent nom tel que require('xyz') de /beep/boop/foo.js, le noeud les recherches de ces chemins dans l'ordre, en s'arrêtant au premier match et générer une erreur si rien n'est trouvé:

/beep/boop/node_modules/xyz
/beep/node_modules/xyz
/node_modules/xyz

Pour chaque xyz répertoire qui existe, le noeud va d'abord chercher une xyz/package.json , pour voir si un "main" champ existe. L' "main" champ définit le fichier qui doit prendre en charge si vous require() le chemin d'accès au répertoire.

Par exemple, si /beep/node_modules/xyz est le premier match et /beep/node_modules/xyz/package.json a:

{
  "name": "xyz",
  "version": "1.2.3",
  "main": "lib/abc.js"
}

alors les exportations de /beep/node_modules/xyz/lib/abc.js sera retourné par la require('xyz').

Si il n'y a pas d' package.json ou pas d' "main" champ, index.js est pris en charge:

/beep/node_modules/xyz/index.js

Answer 4

La grande image

Il semble "vraiment mauvais", mais donnez-lui le temps. Il est, en fait, vraiment bon. L'explicite require()s donner une transparence totale et la facilité de compréhension qui est comme une bouffée d'air frais au cours d'un cycle de vie du projet.

Pensez-y de cette façon: Vous êtes à la lecture d'un exemple, que vous trempez vos pieds dans le Node.js et vous avez décidé que c'est "vraiment mauvais de l'OMI." Vous êtes deuxième deviner les dirigeants de l'Node.js de la communauté, les personnes qui ont enregistré le plus d'heures d'écriture et de maintien de Node.js les applications que quiconque. Qu'est-ce que la chance que l'auteur fait une telle erreur de débutant? (Et je suis d'accord, de mon Ruby et Python arrière-plan, il semble au premier abord comme une catastrophe.)

Il y a beaucoup de battage médiatique et de la contre-battage médiatique autour de Node.js. Mais quand la poussière sera retombée, nous vous reconnaissez que l'explicite et de modules de "premières" paquets ont été un des principaux moteurs de l'adoption.

Le cas le plus courant

Bien sûr, node_modules à partir du répertoire courant, puis les parents, puis les grands-parents, arrière-grands-parents, etc. est recherché. Afin de paquets que vous avez installés déjà de cette manière. Vous pouvez habituellement require("express") à partir de n'importe où dans votre projet et il fonctionne très bien.

Si vous trouvez vous-même le chargement des fichiers en commun à partir de la racine de votre projet (peut-être parce qu'ils sont communs fonctions de l'utilitaire), alors que c'est un gros indice qu'il est temps de faire un paquet. Les paquets sont très simple: déplacer vos fichiers dans node_modules/ et de mettre un package.json il n'. Voila! Tout dans cet espace est accessible à partir de l'ensemble de votre projet. Les paquets sont le bon moyen pour obtenir votre code dans un espace de noms global.

D'autres solutions de contournement

Personnellement, je n'utilise pas ces techniques, mais ils répondre à votre question, et bien sûr, vous savez que votre propre situation mieux que moi.

Vous pouvez configurer $NODE_PATH de votre racine du projet. Ce répertoire sera recherché lorsque vous require().

Ensuite, vous pouvez compromis et nécessitent une commune, local de fichiers à partir de tous vos exemples. Que le bon fichier il suffit de le re-exporte le fichier dans le répertoire grand-parent.

examples/downloads/app.js (et beaucoup d'autres comme ça)

var express = require('./express')

examples/downloads/express.js

module.exports = require('../../')

Maintenant, lorsque vous déplacez ces fichiers, le pire des cas est la fixation d'une cale de module.

Answer 5

Ici est la façon dont je travaille depuis plus de 6 mois. J'utilise un dossier nommé node_modules que mon dossier racine du projet, de cette façon, il sera toujours l'air pour que le dossier de partout que j'appelle un absolu besoin:

• node_modules
  • myProject
    • index.js je peux exiger("myProject/someFolder/hey.js") au lieu de require("./someFolder/hey.js")
    • mondossier qui contient hey.js

C'est plus utile lorsque vous sont imbriquées dans des dossiers et c'est beaucoup moins de travail pour modifier un emplacement de fichier si est définie dans l'absolu. Je n'utilise que 2 la relative besoin dans mon ensemble de l'application.