You are viewing a single comment's thread from:

RE: Isomorphic (ES6 + Node.JS) Module Boilerplate W/ Universal Testing

in #javascript6 years ago

I'm trying to understand the flow of installing a new package. I run npm i <package> and the package is installed in node_modules. Then, if I follow with npm i then gpm will kick in and create the flat dirs. Now we have duplication of packages in node_modules and in the dir above. Is the idea when we deploy, we delete/ignore node_modules?

Another problem is if I want to remove a package, npm uninstall <package> then it removes from node_modules, but all the flat dirs are left — so then all of those would have to be rooted out manually I guess... I suppose that's being nit-picky for the intent, on the other hand, the management doesn't seem scalable even for a relatively small app because well, js library deps...

I DO really like the testing setup though!

Sort:  

Yes I think that section could be clearer. Basically installation should work as normal with npm i or npm i <existing-dependency> The process of adding a dependency right now requires two steps:

  1. Run gpm -n .. -t .. -i <new-dependency>
  2. npm i ../<new-dependency>

I agree that uninstalling is also not covered. I'm debating between adding these as npm scripts or making more PRs to gpm.

As far as the directory structure, I think it is actually easier to scale. Node_modules and webpack are currently obfuscating a snake pit for you. This way everything is de-duped and deployable from a permanent and easily reproducible path.

A classic example would be JQuery. Why import a node build of it to your node_modules, and then jump through build hoops to get it accessible in your other code, at run time? Just keep jquery at /js/jquery in every build, and every module and app will know how to find it.