search

souldzin / fritz-gamera

Repo for our three.js game! Requirements pending...
0 stars 0 forks source link

What do you think about having multiple package.json files? #3

Open JackSkylark opened 7 years ago

JackSkylark commented 7 years ago

When creating a non-server side application, devDependencies do not really work since any production build will require the build dependencies anyways. In order to avoid cluttering the files, I've split them out between build tools / application.

This is an issue on the webpack github. But it relates to NPM as a whole. https://github.com/webpack/webpack/issues/520

souldzin commented 7 years ago

Here's what I think our requirements are:

Single package app?

If we treat our application as having just two modules - dev module (used for development support) and app module (all the app specific code) - then the "devDependencies" / "dependencies" categorization is sufficient. When building our distribution version we can specify to npm install only the production "dependencies" into our "dist" folder.

Multi-package app ?

If we want to split up our app module into packages and specify the dependencies of each package, then I think our alternatives are:

Alternative 1

Put app packages into "nodemodules/@/" and use require("@_/app-package") in code to reference internal packages

Note: I'm using the namespace "_" so that our internal module directory is at the top of the "node_modules" directories.

Alternative 2

Use a tool like lerna to manage the multi package dependencies

Summary

I don't think we need multiple package.json unless we are wanting to split up our app into multiple packages. Anyone who checks out the source will need both devDependencies and dependencies - it makes sense that these are next to each other. But, to meet our requirements, we should create a script to build a distribution version of our application which only includes the production dependencies.

For simplicity sake, I'm leaning towards just having a single package for our app code. Let's keep it in mind that we may need to break it up into packages later, but for now this might be a preoptimization.

So, I'm thinking let's just have a single package.json and use the "devDependencies" / "dependencies" split. Our app will have cohesive inner modules which are in their own directory, and if we need to publish these inner modules somewhere, we'll worry about packaging it when we need to.

What do you think?

JackSkylark commented 7 years ago

I agree with both requirements. I do think that I was preemptively thinking about optimization to our build strategy. My original requirement in mind was to create a application agnostic build package. I don't think that what I used is very intuitive and I agree that we should scrap a multi-project approach unless we end up seeing a natural separation of modules that are self contained.

I think that for now we should refactor the existing codebase to use a single package.json and use "devDependencies" for dev related dependencies and "dependencies" for production dependencies.

ps. I feel like I wasted your time with this multiple packages nonsense. Sorry about that.

souldzin commented 7 years ago

Haha, no worries!

It's tough! It's taken me a while to just accept that node is supposed to be easy and don't worry about "projects" (i.e. C#) unless you really need to.

This obviously comes with some significant trade-offs... thinking of you, >50MB "node_modules" directory just for gulp and express...