I wrote a Next.js app and I'm close to deploying. I would like to know what are the strictly necessary files to copy on the server to deploy while keeping it SSR (not statically generated with next export):
just the .next/ folder?
node modules as well?
any source code?
Copy .next folder with package.json && npm install --production should install only the dependencies of your app.
Keep the folder structure.
Side note, it is bad practice to copy node_modules between environments cause there are some packages that are os specific.
Related
I am new to c++ development environment from javascript dev environment. Comparing to javascript package management, c++ is complicated. I found vcpkg that like npm for cpp.
The question :- When it comes to 'vcpkg' do I need to stage all files (to git) that contains in /vcpkg directory. Or just add it to .gitignore.
The project diretory :-
The /vcpkg directory contains a lot of files, that why I asked.
You shouldn't upload the dependencies to your repository. The correct thing to do is to use vcpkg in manifest mode. This way vcpkg.json package will be used to keep track of your dependencies. Every time you install or remove a package vcpkg.json will be automatically updated eliminating the need to upload your dependencies to your repository. You only need to upload vcpkg.json to your repository which is much faster. It also has many more advantages, take a look at https://vcpkg.readthedocs.io/en/latest/users/manifests/
I have a number of addons that I have modified, all managed with git. When upgrading, I need to be careful to not delete these modules when emptying the node_modules directory in preparation for npm install.
Is there a solution to this, such as nesting customized modules in another directory, either under node_modules or elsewhere? What configuration, if any, would be needed?
You should create your own Ember addons, using original modules as base, instead of manually directly editing addons' files in node_modules directory.
I work on a project where I am the only front-end developer amongst a team of C++ developers. When we build our release variant, I want the C++ developers to run the web build process (npm install, grunt/gulp build which does concat/minification/etc...). In order for that to happen, they have to npm install all the devDependencies.
Is there a way to allow them to quickly install the necessary npm modules without having to re-download them ever time npm install is called? Or make the npm install only go through installation once?
npm link doesn't work since that links to the web application and not the node modules that the web application depends upon.
tar.gz would be possible but that means updating the tar.gz every time a node module gets updated.
Curious what development process others suggest for tacking working in a mixed language environment.
You can checkout node_modules to your git or whatever version control you're using, so they won't be downloaded every time.
Yes, someone will have to update modules once in a while, but some people (including npm itself) do just that.
You can also put a caching proxy server (i.e. sinopia) to download packages from, so downloading would be a bit faster.
I have a Django app running on Heroku that uses Bower to manage front-end dependencies. These dependencies, along with my application, are optimized with RequireJS and served up using Amazon S3. Is there an easy way for me to know what files in my bower_components directory can be safely deleted from my static file server?
I would leave your bower_components folder in your root, untouched and ignored by your VCS. Then use something like Grunt to copy the selected files into a scripts folder somewhere and then use RequireJS to build those.
This allows you to easily update your bower components and prevents you needing to commit needless repository cruft into your repo.
You can use the Grunt concat or copy task to do this or try the grunt-bowercopy task that will also run a bower install for you
The best solution I have found so far is to use django-pipeline to process front-end assets. django-pipeline will:
...help you by excluding much of the extra content that Bower includes
with its components, such as READMEs, tests and examples, while still
including images, fonts, CSS fragments etc.
(from Using Pipeline with Bower)
I am finally going to start using virtualenv for my Django projects on my development machine. Before I start I want to know if there are any special considerations for dealing with my existing projects. My presumed workflow is something like:
make a new virtualenv
activate the new virtualenv
Install Django in there
pip install all the packages I know I need for my existing project
copy my Django project files, app files, and git files into the project folder within the virtualenv.
Edit
6. make requirements file for deployment
This is obviously very simplified but are there any steps or considerations I am fundamentally missing? Is git going to be happy about moving? Also is it best practice to have a separate virtualenv for each Django project?
I know this is not a typical code problem, but I hope those that know more than I do can point me in the right direction.
Many thanks.
I don't see any big issue on migrating your projects and I think your 5-steps plan is correct, in particular, for steps 3/4/5 (I'd merge them), you can handle project dependencies with pip, possibly using requirement files.
Requirement files are plain text files telling to pip which packages have to be installed in your virtualenv, included your git-tracked projects which eventually can be deployed in your virtual environment as development eggs (they bring with them version control infos).
Once you have a req file, it's a matter of:
pip install -r file.req
to have all needed packages installed in your env.
As you can see from virtualenv docs, a typical req file would contain something like:
django==1.3.0
-e git://git.myproject.org/MyProject.git#egg=MyProject
I usually keep each project in its own virtualenv, so I can deploy it to the production server the same way I do for local development.