[Pkg-javascript-devel] please embed modules into package with similar package relations

[Jonas Smedegaard]

Hi all,

When there is a need to embed a module, it is tempting to embed it into 
the package actually needing the module.  But that increases the risk of 
bloated dependency trees and circular dependencies.  Try instead to look 
_back_ in the dependency tree for a place to embed the module which 
imposes the least "baggage" to the embedded module.

Concrete example:

node-cosmiconfig embedded the tiny modules callsites import-fresh 
parent-module, because it needs two of them and they in turn need the 
third.

Later on, eslint need one of those tiny modules as well, and simply¹ 
depends on it.

Problem is, eslint now pulls in not only what it needs, but also 
node-cosmiconfig and all of its _other_ dependencies - which includes 
babel.

Here is a subset of the graph of module runtime dependencies:

cosmiconfig <= parse-json <= @babel/code-frame
            <= import-fresh <= resolve-from
                            <= parent-module <= resolve-from 
                                             <= callsites

Obviously, it was not known when embedding those tiny modules into 
node-cosmiconfig that eslint would later need them.  But it was known 
also back then that cosmiconfig indirectly use Babel at runtime so would 
be a bad host for tiny modules not using Babel at runtime².

Those 3 tiny modules have now been moved to package node-resolve-from, 
which is similarly tiny, with similar dependencies and 
build-dependencies (e.g. uses same same test runner), and are even from 
same author which indicates that they will probably evolve at roughly 
same pace and direction.  After this³ change, eslint pulls in 48 fewer 
package and consumes 15 MB less disk space when installed.

My point is: Best to embed into a _similar_ package, which is likely 
*not* that package triggering the need for embedding.


 - Jonas


¹ or "simply" in quotes: the modules were hidden (i.e. not provided as 
virtual packages) which needed fixing first, but that's another topic.

² use of Babel at _build-time_ can also be problematic, e.g. cause 
circular build-dependencies, this example just happens to be simpler.

³ a future change of providing @babel/code-frame as a real binary 
package instead of its current virtual package would reduce the problem 
at runtime, but possibly not build-time headaches.

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20210101/c712c8f2/attachment.sig>