You can clone with
How to reproduce:
1) App with symlinks (other than symlinks inside node_modules)
2) jitsu deploy
3) Checking what was sent via: tar tvvf npm pack
Symlinks are not bundled in the deploy.
This is an npm issue.
@AvianFlu is there a workaround? Also, do you know if there is an issue in npm to keep track of this?
Ran into this issue myself fixed it by hacking in a predeploy step that fully resolved my symlink and then a postdeploy step to convert it back to a symlink so local dev is using the symlink:
"predeploy": "cd ./example/public && rm webrtc.io.js && cp ../../node_modules/webrtc.io-client/lib/webrtc.io.js webrtc.io.js",
"postdeploy": "cd ./example/public && rm webrtc.io.js && ln -s ../../node_modules/webrtc.io-client/lib/webrtc.io.js webrtc.io.js",
"start": "node example/server.js"
@doughnukem. This is great! I'll give this a go. Thanks.
Yeah, npm purposefully excludes symlinks. We have an issue on it, I'll dig it up if anyone still cares.
@nathan7, would be awesome if you could dig up that issue. Running in to the same problem on my end.
It'd be great to make this configurate in fstream-npm.
Assigning this to @nathan7 for figuring out and such.
Nathan, would be great if you could let us know if it'd be possible at all.
work around nodejitsu/jitsu#379
As long as you guys are using npm to create tarballs, it won't include symbolic links. They're not portable, and npm has to be portable.
It'd probably be good to avoid using npm pack and instead just build your own thing with node-tar.
@isaacs We pretty much want to mirror npm behaviour except for the symlinks and respecting .jitsuignore - I wonder what parts of npm we can reuse
You probably just have to swap out fstream-npm for a similar fstream-jitsu or something. That's where those rules are set.
If symlinks aren't portable, then why do we want to support them @mmalecki / @nathan7 , fixing this issue only partially is silly imho. Wouldn't it make more sense to maybe introduce another field in the package.json like symlinks where users key specify an object where the key is the location of the symlink and the value the path of the original file.. We can probably just resolve these in our module foundry and add it the snapshot?
Also during the packing we could just output a warning that the application contains symlinks and that our platform doesn't support these.
@3rd-Eden They are not portable to Windows. Every modern OS supports it. OS X, Linux, SmartOS. (heck, windows has something close)
@nathan7 that's why i'm suggesting a different approach.
Does nodejitsu's hosting stuff run on Windows?
@isaacs Nope, SmartOS.
I do not think that we should care about Windows at all.
Also, if this feature proves problematic to implement, let's ditch it. I'm fine with going whatever npm thinks is fine.
@mmalecki I have an fstream-jitsu in progress (a fork of fstream-npm, we can pull in future upstream changes easily)
@mmalecki you are technically correct, the best kind of correct. Even if we were to hypothetically add Azure as a deployment target, we would run ontop of their Linux VMs.
The only concern I have is that the solution needs to be runnable on Windows clients (i.e. I should still be able to deploy from a Windows machine to nodejitsu).
@indexzero Unices have symlinks and we handle them incorrectly. Windows doesn't have symlinks, we won't ever encounter them, thus we're handling them correctly already there.
I'm all for closing as WONTFIX and not forking upstream libraries.