Node, mimosa, durandal newb. I'm attempting to install the mimosa skeleton of durandal on windows, as detailed on the durandal website. Running this command:
mimosa skel:new durandal "C:\Users\Anthony\node projects\typelearn"
(quotes because windows and space in path) gives me this error, with the incorrect path for the template installation location:
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)
Removing the quotes around the file path in the command line argument gives the same error. Having a filepath with no spaces gives the same error.
Note that this works fine: C:\Users\Anthony\node projects\typelearn>mimosa skel:new durandal
One question:
how can I get the skeleton to install correctly? It looks like a bug to me: C:\Users\Anthony\C:\Users\Anthony\node projects\typelearn is definitely not a path that exists, yet mimosa is attempting to move the cloned repo there.
I believe I've fixed that bug and I released a new version of Mimosa. I'm unable to test on Windows at this time, but I'm hopeful the solution was cross-platform.
The folder provided was always envisioned to be something in the current directory. But I'm happy to support the use case you've brought up here.
This same issue will bite you on mimosa new too. I'll get that fixed after I release 2.0 sometime later this month.
It looks like the path has to be relative to the current directory so I believe this would have worked:
C:\Users\Anthony>mimosa skel:new durandal "\node projects\typelearn"
since it looks like it automatically adds the current path to the one supplied. So maybe the docs need to be more specific or else the bug is that the command should allow for absolute paths as well.
I think this is a bug. This works fine:
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 created here: https://github.com/dbashford/mimosa/issues/339
Related
I am attempting to get the volar vue language server to work in place of vetur for neovim's native lsp.
Using both lspconfig and lspinstall I was able to create a working custom install for sumneko_lua (unrelated but had to manually build due to some issues with the built-in :LspInstall lua). Below is that code duplicated and modified for an attempt at using this new vue server:
local vue_config = require'lspinstall/util'.extract_config('vuels')
vue_config.default_config.cmd = {'node', './node_modules/vscode-vue-languageservice/out/index.js', '--stdio'}
require'lspinstall/servers'.newvue = vim.tbl_extend('error', vue_config, {
install_script = [[
! test -f package.json && npm init -y --scope=lspinstall || true
npm install vscode-vue-languageservice#latest
]],
uninstall_script = nil
})
Running :LspInstall newvue installs properly, however :LspInfo shows this language server is attached to the buffer (of a .vue file) but not active. I believe the issue is with this path: ./node_modules/vscode-vue-languageservice/out/index.js. It exists, but may not be the correct entry point? The default vue ls simply has vls as the command because it provides a binary. Am I missing something in this package? I have yet to come across another language server without a single binary to pick out.
Thanks!
Can you try an absolute path to the out.js file? In my pretty elaborate config for a custom Volar install I'm using something just /home/myuser/dev/volar/packages/server/out/index.js (where the volar folder is just the whole volar cloned github repo). My full config is here
I don't think you can use relative paths like you did. I know you're assuming that the "./node_modules" means "workspace directory" but it's hard to tell in which directory nvim-lspconfig opens up those executables.
I have yet to come across another language server without a single binary to pick out.
Volar also provides a binary, it's volar-server (after running npm i -g #volar/server), it's just with a custom install (ie. alongside the real volar) you can't use it, because I assume you want to use your local install with custom code.
As for more indepth debugging/logging, you can check ~/.cache/nvim/lsp.log to see why the language server dies in detail.
I got this problem when I use git svn to checkout my svn repos.Then I follow some suggestions from website and try to reinstall svn:core by
sudo cpan SVN:Core
but I still got following error when I try to check out a svn repos.
dyld: lazy symbol binding failed: Symbol not found: _svn_ra_make_callbacks
Referenced from: /usr/local/Cellar/perl/5.32.0/lib/perl5/site_perl/5.32.0/darwin-thread-
multi-2level/auto/SVN/_Ra/_Ra.bundle
Expected in: flat namespace
dyld: Symbol not found: _svn_ra_make_callbacks
Referenced from: /usr/local/Cellar/perl/5.32.0/lib/perl5/site_perl/5.32.0/darwin-thread-
multi-2level/auto/SVN/_Ra/_Ra.bundle
Expected in: flat namespace
error: git-svn died of signal 6
I check from website that the function is declared in the library header:
libsvn_swig_perl/swigutil_pl.h
But I didn't find error message related this lib (I did see some warning) when I install SVN:Core.
Are there something I need to setup or check for this issue when I install SVN:Core to make my git svn check out work properly?
Thank you~~
Eric
You should not need to manually install Perl package SVN::Core. The Homebrew formula subversion already does that — but, only for Intel hardware currently, as you can see. Volunteering to contribute other hardware support would be warmly welcome.
That formula (script) is what powers brew install subversion. Does this command work for you at all? Can you run svn info? If not, then you should first of all get svn installation working — and only then add git-svn on top. This is because the dependency structure looks like this:
If the bottom-most box is broken for you, then messing with Perl packages is guaranteed to not help.
I check from website that the function is declared in the library header
Please be specific; which website? I don't see any _svn_ra_make_callbacks in the latest upstream source, neither in 1.14.1 tarball.
I tried to create a nuxt app with the guide from the official website, chose default options because I wanted the starter template but on running npm run dev, I keep encountering the error:
This relative module was not found:
* ./components/nuxt-error.vue in ./.nuxt/index.js
I've tried searching about it but I couldn't find any useful resource/fix. I've also tried vue init nuxt-community/starter-template for the installation but I still get the same error.
Any fixes?
So I found a solution. I couldn’t figure out the error because the nuxt-error.vue file was actually imported correctly. Turns out “npm” installations have been giving me issues (had issues with TailwindCSS too).
So if you ever encounter this error on loading the base nuxt app, recreate the project using “yarn” instead. Works like magic!
This Error basically means, that in one of your files you are trying to import another file with the relative path of ./components/nuxt-error.vue but no file with this path exists.
However
I just read that vue init nuxt-community/starter-template is deprecated and no longer maintained. Instead of fixing this Error you should restart your project with npx create-nuxt-app <yourAppName>. https://github.com/nuxt-community/starter-template
So I've been working on a Vue.js project for couple times now, and I am facing a problem I've never seen before.
Trying to git pull the project on another computer, or even downloading the project as a zip file, when it's time to npm install, vue-material module fails and the whole thing cannot be run.
It goes this way, with vie-material :
vue-material#1.0.0 postinstall C:\<my_things>\node_modules\vue-material
sh build/git-hooks/install.sh
Then I see this :
/usr/bin/bash: build/git-hooks/install.sh: No such file or directory
Then the modules' tree shows in the terminal, and at the end, I can see all the errors related to vue-material, with this statement :
Tell the author that this fails on your system:
sh build/git-hooks/install.sh
By the way, I tried to crate a brand new Vue project, and tried to add vue-material inside, no problem, so it has to do with my project.
Obviously though, /usr/bin/bash does not exist, since I'm running Windows 10.
Any knowledge on npm's installing routine ? I'm out of solution to try...
Can you share your package.json file?
I had this same problem just now and found that NPM could possibly be installing the incorrect version. Where I had "^vue-material": "1.0.0-beta-7" NPM was installing version 1.0.0 instead of 1.0.0-beta-7. If you remove the ^ then it may work for you. This is where I found the answer that helped me.
https://github.com/vuematerial/vue-material/issues/1155
Well, after couple times figuring out what was wrong, I got this :
I tried to use yarn and it told me that my node version was too old (vue-material needed 7.0+ and my node was 6.9, or at least that is what yarn told me), so I got myself the 8.9.3 node.
After this I tried to use yarn again, and the error with that bash script showed again.... then I just tried to use npm install again, and it worked just fine...
I don't know about the bash script thing, but one thing to remember is to always check for node and npm's version when errors happend.... (and yarn looks very cool and simple imo ^^).
You kinda made me think about a version problem though, I got you that ! :D
Problem solved....
When setting advanced properties on a program/link to start as another user it is throwing the error:
Sorry - Plasma
KDEInit could not launch 'kdesu':
Could not open library 'libkdeinit5_kdesu'.
Cannot load library /run/current-system/sw/lib/libkdeinit5_kdesu: (/run/current-system/sw/lib/libkdeinit5_kdesu.so: cannot open shared object file: No such file or directory)
I tried to install kdesu using:
[root#nixos:~]# nix-env -qaP kdesu
nixos.kdeFrameworks.kdesu kdesu-5.36.0
[root#nixos:~]# nix-env -iA nixos.kdeFrameworks.kdesu
replacing old ‘kdesu-5.36.0’
installing ‘kdesu-5.36.0’
building path(s) ‘/nix/store/2bn27h5drw0800gk5z2rmwfx78gqbbdc-user-environment’
created 2209 symlinks in user environment
[root#nixos:~]# kdesu
bash: kdesu: command not found
[root#nixos:~]# which kdesu
which: no kdesu in (/root/bin:/run/wrappers/bin:/etc/per-user-pkgs/root/bin:/root/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin)
I also tried installing nix-env -iA nixos.kde-cli-tools but that does not work either.
Any suggestions on how to get kdesu installed on NixOS?
As a general rule, unlike many distros on NixOS installing a library directly doesn't work as intended; the application that needs the library won't be able to find it. Instead, the package must declare all it's dependencies.
Packages which have optional dependencies tend to have a way to add them via configuration. You may want to try something like this in /etc/nixos/configuration.nix
services.xserver.desktopManager.plasma5.extraPackages = with kdeFrameworks;
[ kdesu
];
I'm glad to see that you filed an issue on Nixpkgs, because this is not a configuration issue but a packaging bug.
It looks like kdesu lives in some libexec dir that doesn't hasn't been added to your PATH. It belongs to the kde-cli-tools package. You can run it with
$(nix-build '<nixpkgs>' -A kde-cli-tools --no-out-link)/lib/libexec/kf5/kdesu
You can use the above as an alias to launch kdesu until the fix to the packaging bug arrives.