4

Mobx DevTool's README guides you to install it as dev dependency, and then import it into your code. That seems like a problem to me, because devDependencies, as explained by this SO answer, are:

... used for the build process, tools that help you manage how the end code will end up, third party test modules, (ex. webpack stuff)

If that's true, then is it a correct deduction that you shouldn't import a devDependency into your code?

craftsman
  • 15,133
  • 17
  • 70
  • 86
  • What kind of code are you importing it into? Is this code for a tool that will only ever be run in a development context, or is this code also going to be used by a consumer of your module/library/tool? – zero298 Mar 08 '19 at 18:14
  • It'd be embedded within the app (it'd overlay some buttons on top of your web page), and used by developers for debugging. But it's not intended to be used only in dev environment. – craftsman Mar 08 '19 at 18:15
  • 1
    `But it's not intended to be used only in dev environment` Then make it a dependency and not a devDependency. It technically doesn't really matter if you're rolling it all up before you ship it. But it's good practice to understand what devDependencies are (used for building/testing your code) and what dependencies are (required by your running production code). – Adam Jenkins Mar 08 '19 at 18:19
  • Oops, sorry! I was rushing to a meeting and I mistakenly put a not there in a rush. SO doesn't let me edit my comment, so here is what I meant to say: `But it's intended to be used only in dev environment` Which means it can be made a devDependency? If that's true then, now that we have an import statement in the code referring to this dependency, what would happen when creating a production build? Would it break the code in production? – craftsman Mar 08 '19 at 18:38

1 Answers1

4

It depends on how the code that will import the dependency will be used. If it will only be used in a development context, then yes, it should be a devDependency and it's fine for the code to use it.

If the code that uses it is going to be used by a consumer of your package/module/library, then it is a direct dependency and should be annotated as such.

It's kind of how you view the intention of the source file that consumes the dependency. If I install with npm install your-cool-package, I don't want, and shouldn't need the devDependencies installed because I'm likely not going to be building your module from source, benchmarking, or testing. I'm just going to consume it.

If I need the dependency to consume your module, then it isn't a devDependencies, it is just a straight up dependencies (or maybe a peerDependencies).

Ask yourself this: When I use your module, for it to function, does the dependency need to be there for it to function? If it does, it's a dependency. If not, it's a dev dependency.

If you author a plugin for something, it depends on the thing it plugs in to. If you author a plugin that helps people develop things, the plugin still depends on what it plugs in to, but the person installing your plugin would consider your plugin a development dependency because they don't need it when they aren't developing. However, your plugin still depends directly on the thing that it plugs in to.

It sounds like you are writing a plugin (let's call it cool-plugin) for a module (Mobx). I don't use Mobx, but it sounds like a development tool. Since it sounds like cool-plugin needs Mobx in order to do anything Mobx is a dependency of cool-plugin, but a consumer would consider cool-plugin a devDependencies of their own hypothetical consumer-module because they don't need it in production.

Because of that, you should consider Mobx a dependencies because your module doesn't make sense without it.

There is a case to be made that you should actually consider it a peerDependencies because consumer-module probably doesn't want you to install your own version of Mobx but instead wants you to interface with the one they should already be using.

zero298
  • 25,467
  • 10
  • 75
  • 100
  • So in my context, I can make it a devDependency right (since I'm only going to use it in development environment)? If that's true then, now that we have an import statement in the code referring to this dependency, what would happen when creating a production build? Would it break the code in production? – craftsman Mar 08 '19 at 18:40
  • 1
    @craftsman See my edit, I think Mobx should be a **dependency** and not a devDependency if my understanding is correct. – zero298 Mar 08 '19 at 19:36