Benjamin Martin
If you've been following along with my Docker series (you can find my latest article about Continuous Integration (CI) here ) then you must be pretty happy to have your CI pipeline solving all the world's problems. Your developers are pretty content, but we know there's more we could do. And, I mean, isn't developer happiness the real reason you're reading a DevOps article?
You're at work and your team has adopted Docker for development. That's great! Everyone is using your custom Docker image to manage dependencies and any other environment requirements. You've nearly made it look just like your production environment. High five!
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.
Learning development on the JavaScript stack can sometimes be quite frustrating (even with tools like Node or NVM). 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. You may have some legacy apps that you don't touch very often, but you want your host machine to have the latest and greatest when you start your next project. That's understandable and we've all been there before.
So you've just written this super awesome directive for Angular that does all the things and has all the tests. It's been committed, pushed and you've opened a Pull Request! All done! Awesome! High five! Woo!