L'installation de durandal modèle avec mimosa semble se briser au moment de donner un chemin d'accès

Question

Nœud, de mimosa, de durandal newb.Je suis d'essayer d'installer le mimosa squelette de durandal, sur windows, comme détaillé sur la durandal site web.L'exécution de cette commande:

mimosa skel:new durandal "C:\Users\Anthony\node projects\typelearn"

(entre guillemets parce que windows et de l'espace dans le chemin d'accès) me donne cette erreur, avec le chemin d'accès incorrect pour le modèle de l'emplacement d'installation:

C:\Users\Anthony>mimosa skel:new durandal "C:\Users\Anthony\node projects\typele
arn"
13:16:11 - Retrieving registry...
13:16:11 - Found skeleton in registry
13:16:11 - Cloning GitHub repo [[ git://github.com/BlueSpire/Durandal-Mimosa-Ske
leton.git ]] to temp holding directory.
13:16:13 - Moving cloned repo to  [[ C:\Users\Anthony\C:\Users\Anthony\node proj
ects\typelearn ]].

fs.js:642
  return binding.mkdir(pathModule._makeLong(path),
                 ^
Error: ENOENT, no such file or directory 'C:\Users\Anthony\C:\Users\Anthony\node
 projects\typelearn'
    at Object.fs.mkdirSync (fs.js:642:18)
    at _moveDirectoryContents (C:\Users\Anthony\AppData\Roaming\npm\node_modules
\mimosa\node_modules\skelmimosa\lib\command\new.js:87:8)
    at C:\Users\Anthony\AppData\Roaming\npm\node_modules\mimosa\node_modules\ske
lmimosa\lib\command\new.js:64:5
    at ChildProcess.exithandler (child_process.js:635:7)
    at ChildProcess.EventEmitter.emit (events.js:98:17)
    at maybeClose (child_process.js:735:16)
    at Socket.<anonymous> (child_process.js:948:11)
    at Socket.EventEmitter.emit (events.js:95:17)
    at Pipe.close (net.js:466:12)

Enlever les guillemets autour du chemin d'accès au fichier dans l'argument de ligne de commande donne la même erreur.Avoir un chemin d'accès, sans espaces donne la même erreur.

Notez que cela fonctionne bien: C:\Users\Anthony\node projects\typelearn>mimosa skel:new durandal

Une question:

• comment puis-je obtenir le squelette de l'installer correctement?Il ressemble à un bug pour moi: C:\Users\Anthony\C:\Users\Anthony\node projects\typelearn n'est certainement pas un chemin qui existe, pourtant, le mimosa est de tenter de déplacer le cloné des pensions de là.

Answer 1

Je crois que j'ai corrigé ce bug et je l'ai publié une nouvelle version de Mimosa.Je ne suis pas en mesure de tester sur Windows à ce moment, mais j'ai l'espoir de la solution a été de la croix-plate-forme.

Le dossier fourni était toujours imaginé être quelque chose dans le répertoire courant.Mais je suis heureux de soutenir le cas d'utilisation que vous avez apporté jusqu'ici.

Cette même question va vous mordre sur mimosa new trop.Je vais obtenir ce corrigé après que j'ai libération 2.0 quelque temps plus tard ce mois-ci.

Answer 2

On dirait que le chemin doit être relatif au répertoire courant je crois que cela aurait fonctionné:

C:\Users\Anthony>mimosa skel:new durandal "\node projects\typelearn"

depuis, on dirait qu'il ajoute automatiquement le chemin d'accès actuel à celui fourni.Alors peut-être que les docs ont besoin pour être plus précis, sinon le bug, c'est que la commande doit permettre de chemins absolus ainsi.

Answer 3

Je pense que c'est un bug.Cela fonctionne très bien:

C:\Users\Anthony\node projects\typelearn>mimosa skel:new durandal
14:28:11 - Retrieving registry...
14:28:11 - Found skeleton in registry
14:28:11 - Cloning GitHub repo [[ git://github.com/BlueSpire/Durandal-Mimosa-Ske
leton.git ]] to temp holding directory.
14:28:13 - Moving cloned repo to  [[ C:\Users\Anthony\node projects\typelearn ]]
.
14:28:13 - Cleaning up...
14:28:13 - Skeleton successfully cloned from GitHub.

C:\Users\Anthony\node projects\typelearn>

Bug créés ici: https://github.com/dbashford/mimosa/issues/339