-
Notifications
You must be signed in to change notification settings - Fork 51
-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Put node_modules in linked_dirs? #7
Comments
I actually had this as a recommendation in the README a long time ago. See f4224f5. I think it was removed because of this npm bug npm/npm#1727 which has since been resolved. There may have been another reason but not that I can remember. One downside to having |
Uh, I didn't think of rollbacks, you're right. How is that managed for capistrano/bundler? It runs Anyway, for my use case I think I'll keep |
Looks like it isn't managed at all by the bundler plugin. They only run Seems like they should also hook into |
Having faster deploys is sure a nice to have feature. If there aren't other edge cases, I'd go for it (also for Bundler, Composer and others). We could gain faster deploys (the downside is that rollbacks will become slower because they have to run |
I would like to vote for faster deploys as well. Having to install the same packages over is problematic on production servers as that can take up a lot of resources affecting actual production workload. |
I'm still going to think about this, but just note that you can easily do this yourself for now with: set :linked_dirs, %w{node_modules} And if you want rollbacks to be auto just add: before 'deploy:reverted', 'npm:install' |
@swalkinshaw Thanks for the update. Somehow I missed that. For now, I will def go with this workaround. Just a quick question, does the set command overwrite the list or does it push it? |
@akshah123 it would override it, you want to add in set :linked_dirs, %w{logs node_modules} |
Cool. Anybody else looking at this, I used following so that it would push instead. This is so that it doesn't play foul with any other modules such as rails. # Default value for linked_dirs is []
linked_dirs = Set.new(fetch(:linked_dirs, [])) # https://github.com/capistrano/rails/issues/52
linked_dirs.merge(%w{node_modules})
set :linked_dirs, linked_dirs.to_a |
I am lacking documentation, but I wrote this library to address exactly this problem https://github.com/capistrano/copy-files. Instead of sharing dependencies, it can copy a directory from a previous release, into the new release |
npm maintains a local cache and there's the extension above which would make deploy faster. So I'm closing this. |
@swalkinshaw npm's cache doesn't include anything compiled. For example, |
@c0 never knew that, thanks. But even so there's an extension to manage this: https://github.com/capistrano/copy-files |
@c0 good pint, so what you can suggest for speed up |
+1 I would also like to know.. |
I think it's a good idea to reopen and discuss on this issue and document all this stuff in the readme. |
@milushov @lichtamberg to skip compilation in node-sass you just need to use copy-files to copy the set :copy_files, ['node_modules'] You may also want to prune the directory before before 'npm:install', 'npm:prune' |
As the title suggests, what do you think about it?
The main advantage would be to speed up deploys, and as I see bundler plugin does a similar thing (although Bundler supports saving to a different path natively, npm will always install to
./node_modules
).I don't know if this is possible from the npm plugin itself (I have little Ruby and capistrano internals knowledge), but we can at least give a hint to users in the read me.
At the moment I simply added
in
deploy.rb
and it works perfectly.Thanks.
The text was updated successfully, but these errors were encountered: