Actually, my biggest project, SHPS was managed as one application with many sub-modules. The code base grew and it became harder and harder to maintain (even though I am just one developer pushing out updates). So last month I decided: It's time! I carved out all the modules and put them into separate NPM packages. This decision has a lot of advantages, for example:

• When working on the code, I do not have to worry about other branches and merging lots and lots of code
• I can have different versions of dependencies for each module which means I can adopt newer breaking versions faster where needed
• It is easier for external contributors to understand a module's code and modify it
• In certain cases, the different modules can be installed in a newer version than allowed by the main project to get early access to new features
• Developing new features becomes a lot easier with one installation of the project, as all I have to do is work in one module, commit&push the changes, then re-install the module to reset the features for working on the next issue or feature (instead of re-installing the whole application)
• It is easier to see the interfaces of each module
• Modules can be easily exchanged by other modules (even 3rd party ones) as long as the API remains the same.

All in all it makes for a nice decoupled feeling!

You should always start small. When your codebase becomes huge, you can push out some parts into separate stand-alone dependencies but again if there is a reason. You can use npm to work with local files and repos also. Companies usually have some kind of libraries they use in all projects.

Imagine it like a Bootstrap and many of your projects where each of them uses Bootstrap. You don't need to write buttons, carousels, dropdowns all the time, you just pull components you need and ready to go. When something changed in a dropdown, for example, you can automatically update all your projects instantly.

Here is a good talk:

But again, don't overcomplicate things until it is really needed and never push out each small module into another small package. Create a library of modules instead.

Okay, I have to say, after a few days of trying this I moved everything back to modules. I'm not saying that splitting out modules into their own packages is a bad pattern. But I really did so consistently with all modules. I'm talking about 10 modules. Especially at the initial phase when refactoring everything to work with this new split architecture, I lost a lot of time building the packages, publishing them and updating them, only to see some incompatibility and start all over. So if you want to try this do it with modules that are already quite stable, and especially not with all modules at once ;)

To add some context: I'm actually trying this approach in my project. Each "module" is its own git repo + npm package. I use https://github.com/verdaccio/verdaccio as a private registry. It's an interesting experience, but kind of painful to get started from an existing project: for every mistake you detect in your project, you need to go change the specific module, build it, commit, publish a new version and import it in the main project. Which can also be a good thing because you end up testing much more on a per-module basis.

It depends on the cases. With the functions that work as general helpers or utils, I tend to build them as NPM packages.