Skip to content
This repository

jitsu deploy not bundling symlinks #379

sam3k opened this Issue January 22, 2013 · 20 comments

9 participants

sam3k Nathan Zadoks Maciej Małecki Charlie McConnell Doug Daniels Brian Neisler Isaac Z. Schlueter Arnout Kazemier Charlie Robbins

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.

Charlie McConnell

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?

Doug Daniels

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:

"scripts": {
    "predeploy": "cd ./example/public && rm && cp ../../node_modules/",
    "postdeploy": "cd ./example/public && rm && ln -s ../../node_modules/",
    "start": "node example/server.js"

@doughnukem. This is great! I'll give this a go. Thanks.

Nathan Zadoks

Yeah, npm purposefully excludes symlinks. We have an issue on it, I'll dig it up if anyone still cares.

Brian Neisler

@nathan7, would be awesome if you could dig up that issue. Running in to the same problem on my end.

Maciej Małecki

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.

/cc @isaacs

skivvies referenced this issue from a commit in getlantern/lantern-ui April 03, 2013
work around nodejitsu/jitsu#379 9102bce
Isaac Z. Schlueter

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.

Nathan Zadoks

@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

Isaac Z. Schlueter

You probably just have to swap out fstream-npm for a similar fstream-jitsu or something. That's where those rules are set.

Arnout Kazemier

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.

Nathan Zadoks

@3rd-Eden They are not portable to Windows. Every modern OS supports it. OS X, Linux, SmartOS. (heck, windows has something close)

Arnout Kazemier

@nathan7 that's why i'm suggesting a different approach.

Isaac Z. Schlueter

Does nodejitsu's hosting stuff run on Windows?

Nathan Zadoks

@isaacs Nope, SmartOS.

Maciej Małecki

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.

Nathan Zadoks

@mmalecki I have an fstream-jitsu in progress (a fork of fstream-npm, we can pull in future upstream changes easily)

Charlie Robbins

@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).

Nathan Zadoks

@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.

Maciej Małecki

I'm all for closing as WONTFIX and not forking upstream libraries.

Maciej Małecki mmalecki closed this April 27, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.