To run Homestead, the following software must be installed on your host machine.
Install vagrant by downloading the latest version (currently: v2.0.1 as of January 29th 2018)
<h1 id="vagrant-for-various-versions-of-php">Vagrant for Various Versions of PHP</h1> | |
<h1 id="requirements">Requirements</h1> | |
<p>To run Homestead, the following software must be installed on your host machine.</p> | |
<h2 id="vagrant">Vagrant</h2> | |
<p>Install vagrant by downloading the latest version (currently: <strong>v2.0.1</strong> as of January 29th 2018)</p> | |
<ul> | |
<li><a href="https://www.vagrantup.com/downloads.html">https://www.vagrantup.com/downloads.html</a></li> | |
</ul> | |
<h2 id="virtual-box">Virtual Box</h2> | |
<p>Install virtual box by downloading the latest version (currently: <strong>v5.2.6</strong> as of January 29th 2018)</p> |
To run Homestead, the following software must be installed on your host machine.
Install vagrant by downloading the latest version (currently: v2.0.1 as of January 29th 2018)
Learning development on the JavaScript stack can sometimes be quite frustrating (even with tools like Node or NVM). But this is especially true when you manage different applications with different environment dependencies (or different versions of node, npm etc..) for each app that you're developing. Maybe you have some legacy apps that you don't feel like touching, but you want your host machine to have the latest and greatest when you start you next project. That's understandable and we've all been there before.
I used to reach for VMs for all my work. I have a former love affair with Vagrant. Back when I was working on the LAMP stack, it made managing my various projects dependencies and environments a breeze. The VMs helped to ensure consistent behaviour between my
In case you missed the first part in this series, [check this link here] to learn more about the command line interface that Docker ships with. We'll be using these commands in this section. If you are already familiar with Docker CLI, feel free to skip part 1 and jump right in.
So, now that we're familiar using Docker in the terminal, let's use what we've learned to Dockerize our application. I'll be using the 'out-of-the-box' app the the Vue CLI provides. (This is just because I love how simple their CLI is and I love working with Vue. These steps can easily be applied to whatever frontend application you're building.)
Let’s take a moment to consider what is important for local development. For me, I want to make sure all my developers are using the same dependencies, and I don't want to worry about what versions they have installed. No more “but it works on my machine” excuses. At the same time, I want to make sure we retain the conveniences of HMR (Hot Module Replacement) so that developers don't need to constantly refresh the application to see their changes reflected. We don’t want to lose fast feedback.
In this article, we'll look at how we can setup Docker for a boilerplate VueJS app with custom Dockerfile
s from which our images and containers will be built and how we gain efficiencies from these.
In case you missed the first part in this series, check here to learn more about the command line interface that Docker ships with. We need to use the commands from that article in this se
FROM node:9.11.1 as devBuild | |
## Set ENV Variables in the Image | |
ENV NODE_ENV=development | |
ENV PORT=8085 | |
ENV BABEL_DISABLE_CACHE=1 | |
## Prep node_modules | |
COPY package*.json /tmp/ | |
RUN cd /tmp && npm install |
# Builder | |
FROM node:9.11.1 as builder | |
COPY package*.json /tmp/ | |
RUN cd /tmp && CI=true npm install | |
WORKDIR /usr/src/app | |
COPY . /usr/src/app/ | |
ENV NODE_ENV=production | |
RUN cp -a /tmp/node_modules /usr/src/app/ && npm run build |
{ | |
"name": "e2e", | |
"version": "1.0.0", | |
"description": "", | |
"main": "index.js", | |
"directories": { | |
"test": "tests" | |
}, | |
"devDependencies": { | |
"cypress": "^3.1.2" |
{ | |
"browser": "chrome", | |
"pluginsFile": "tests/e2e/plugins/index.js" | |
} |