Do "dependencies" and "devDependencies" matter when using Webpack?

When using Webpack to bundle your application for production, where you put your dependencies in package.json doesn't matter - as Webpack will simply follow all import statements, starting with the entryPoint.

So what do you do? Can you just put your dependencies anywhere? Well, yes :)
Here are 3 common approaches I've seen.

#1 Putting all dependencies under "devDependencies"

This approach considers that since your production app (aka the bundle you built with Webpack) can just run by itself, it means you have no production dependencies. Thus, all dependencies are devDependencies. 

This is how VueJs and React specify their dependencies.

#2 Putting all dependencies under "dependencies"

This approach sees the web application itself as a "builder" application for the final app. Thus, everything the app needs to build the final bundle is a dependency - including Webpack, babel etc. - and goes into dependencies.

This is useful since your build will work in CI even if you set the env to production:

NODE_ENV=production npm install # Skips devDependencies

#3 Separating them into devDependencies and dependencies, even if they're not used per se

This approach acknowledges that where you place the dependencies doesn't matter for the final bundle, but follows the Node convention anyway for better readability.

This is useful to communicate to other devs the intention of each dependency - whether it's a dev tool or a library for production.

This comes with the added benefit of better integration with other tools, since it follows a well known convention.

One example that comes to mind is checking your web app for security vulnerabilities with a tool like Snyk: running snyk test will by default only look under dependencies, not reporting any vulnerabilities in devDependencies. This is expected, however imagine you have everything under dependencies or everything under devDependencies - it becomes much harder to tell what vulnerability you're actually shipping with your code.

Which approach are you using?

My preference goes to the third approach described above, because of the better readability and following a well known convention.

What approach do you use? Do you have a preference for any particular approach? What pros and cons did you find?
Let us know in the comments below!