CODEWITHSUNDEEP
node.jsnpmdeploymentwebpackgulp
pjk_ok
pjk_ok

Reputation: 947

Gulp / NPM Dev dependencies - What do I do with them when my site is finished?

I've started learning Gulp and Webpack and one thing none of the tutorials cover is... when your project is finished and ready to be deployed - what do you do with / what happens to all the dev dependencies?

The node_modules folder itself is huge and I'm assuming you don't upload this to your web server(or maybe you do)? But then does that mean all the benefits you get from using things like SASS/minification are only available on your localhost project, and therefore it's only the finished files that get deployed (which would then mean having to edit minified code etc live on the site if you need to make any small changes).

This part of the learning process is harder to find info about than anything else I've experienced so far in web development. I also think it's poor none of the major learning libraries (Lynda, Treehouse etc) cover this at the end of the tutorials. It's like, congratulations you've now built a site you can upload. OK, but what do I do with the hundreds of files in all of my dependencies etc? Do I upload them normally as part of the site, and if not do how do I prevent this or does npm prevent this automatically?

Any guidance/explanation would be amazing.

Emily

Upvotes: 0

Views: 1053

Answers (1)

Mika Sundland
Mika Sundland

Reputation: 18939

There are many different ways to deploy a project. The technology it's based on, team size, project size, project importance and many other things are important factors that determine how it should be done. I can't go into how it's done in big projects, as that's an entire field in itself, but I can give you a few pointers on how to get started.

There are generally four strategies you can choose when you deploy your code:

  1. Build on the server during deployment.
  2. Build before deploying and deploy both node_modules and the production files.
  3. Build before deploying and only deploy the production files.
  4. Deploy using a container.

Build on the server

With this strategy, you upload everything in your repository to the server. By repository I mean your source code repo, not the entire project folder. Ignored files and folders (in .gitignore, if you're using git) are not uploaded, meaning you don't upload node_modules or the files gulp builds. I assume you don't track these files and folders with version control. After the files have been uploaded you run npm install --only=production and gulp on the server.

When you run npm install with production mode enabled it only downloads and installs the dependencies. devDependencies are skipped. You might wonder how you run gulp without installing it. Well, you have to move all the gulp-related modules into the dependencies section. That same goes for the modules you are using in the gulpfile, such as babel and webpack.

The app should be set to serve the files made by gulp. If you are using Express and the files gulp makes are in a folder called dist, it would look something like this:

app.use(express.static(path.join(__dirname, 'dist')));

This build process is usually made automatic when you are using a hosting-in-the-cloud provider such as AWS Elastic Beanstalk or Heroku. To deploy to Heroku, for example, you push a branch in your repo to a remote repository on Heroku. Heroku will then run npm install automatically, and after that run the postinstall script that you define in package.json. If you set up the postinstall script to something like this:

"scripts": {
  "start": "node app.js",
  "postinstall": "gulp"
}

it will run gulp for you automatically when you are pushing your changes. The workflow then consists of doing changes locally, committing your code and pushing the branch with the changes to Heroku. Heroku will handle the npm and gulp stuff. It will also restart the app after the build is complete. Elastic Beanstalk is similar.

I would recommend this strategy. It works well with continuous integration. AWS and Heroku also have free tiers so you can experiment there as much as you want.

Build before deploying and upload both node_modules and production files

You can also choose to build everything before deploying. The build process mentioned above had two steps: running npm install on the server to create node_modules and then running gulp on the server to create the production files.

For this strategy you

  1. Run gulp inside your working folder (locally) to create the production files.
  2. Copy the production files, as well as package.json, into a new folder.
  3. Run npm install --only=production inside the new folder to create node_modules.
  4. Make sure the app works inside the new folder and then upload it to the server.

You don't run npm install or gulp on the server in this case. Instead, you provide all the files that are needed. I don't think I've ever seen it been done this way though. It doesn't work well with the hosting providers I have mentioned, as they want to run npm install themselves.

Build before deploying and upload only production files

Not running npm install on the server during deployment, like mentioned in the strategy above, is not very common. However, it's quite common to skip the gulp-on-server step. Instead of having all the gulp modules in dependencies you keep them in devDependencies. You now:

  1. Run gulp locally to create the production files.
  2. Copy the production files, as well as package.json, into a new folder.
  3. Upload the new folder to the server.
  4. Make sure npm install --only=production is run on the server.

This is quite easy to do with Elastic Beanstalk, for example. All you have to do is upload a zip file with the production files and package.json, and it will run npm install for you automatically after the upload is complete. It will also start the app after the installation is complete.

Using containers

This strategy uses technology such as Docker to create a container containing everything that's needed to run Node. That means the OS, Node, npm, your code etc. You then upload the container to a hosting solution that accepts containers, such as AWS. It's not very hard, but I would advise you to get used to "ordinary" deployment methods first.

You mention doing small changes to the code on the server. I would advise you not to do that. You should edit the code locally instead, then make sure it works on the local server, and finally upload the changes after committing. Your repo should reflect the live code.

Finally, I would recommend you to create accounts on either Heroku or AWS or both. Just mess around with it and see how it works, that's usually the best way to learn. It's free and you can't break anything.

Upvotes: 6

Related Questions