Bundled dependencies end up in node_modules

[ljpengelen]

For example, i18n-js is part of bundle.js. If you add Maji to your project, i18n-js will also end up in your node_modules folder. This could hold for other dependencies as well. I didn't have time to dive into it.

[pascalw]

This is interesting. It's because the maji package specifies i18n-js as a dependency, but then also includes it in the bundle.js. This can't really hurt (the dependency is not included twice or something), but it does mean the node_modules/ is larger than it has to be.

I think we have 2 options to solve/improve this:

1. We make these dependencies devDependencies, as they are only required during dev to produce the library bundle.js.
2. We mark them external in Rollup.

I briefly looked for some common wisdom on this but couldn't find it. I prefer option 2. WDYT @ljpengelen @ruisalgado ?

[ljpengelen]

As far as I can tell, option 2 is what most people do. If i18n-js were an npm package, going with option 2 would allow npm or yarn to pick a single appropriate version of i18n-js in a project that has a (nested) dependency on both "i18n-js@^3.0.0" and "i18n-js@^3.1.2", for example. This seems to be the main reason to prefer option 2.

It will probably not matter in practice, but this could be the type of situation where going for option 1 would make sense. i18n-js isn't an npm package, so the story above doesn't hold. Theoretically, however, fnando could delete the repository for i18n-js and that would have immediate consequences for new installations of Maji if you went for option 2. That's usually not a reason to avoid option 2 because it's harder to unpublish an npm package than it is to delete a Github repository.

Going for option 2 would make i18n-js an explicit nested dependency for any end user of Maji. Option 1 somewhat hides the fact that i18n-js is a dependency for Maji users. That would make it harder to for them to determine that they need to include a copy of its license in their end product.

I'd say assume that the repository for i18n-js will live forerver and go with option 2.

[ruisalgado]

lets go with 2 then. Either approach seems fine.