search

americanpanorama / panorama

Panorama visualization toolkit (START HERE)
http://americanpanorama.github.io/panorama/
ISC License
63 stars 16 forks source link

Let's talk about dependencies... #12

Closed mojodna closed 8 years ago

mojodna commented 8 years ago

peerDependencies don't make sense because npm 3 doesn't install them, introducing an extra step before being able to work on this module. Conceptually, they're right for the non-bundled, webpack-ed build.

dependencies seems like the most appropriate way of defining them (they install when developing on this and are included for npm-style resolution), but it adds to the footprint when only the bundled assets are used.

devDependencies would install necessary runtime libraries and facilitate bundling (and keep the footprint small), but it would preclude npm-style module resolution (because nested modules would be unavailable).

10's approach (facilitating npm-style resolution, which we're not currently doing) seems like the most appropriate mechanism for our use-cases, but we're also trying to hit these:

  1. bundled assets, suitable for inclusion via <script>, with external (to avoid potential duplication) references to compatible dependencies (e.g. Leaflet, d3, ...)
  2. bundled kitchen sink, suitable for inclusion via a single <script> tag (including all dependencies).

We're currently using (1), but incorporating it into a separate build system and potentially introducing confusion around how to incorporate upstream dependencies (e.g. react-leaflet).

Thoughts?

ericsoco commented 8 years ago

I'm not sure that supporting inclusion via <script> is something we really want to aim for. We're targeting an intermediate+ JS developer audience, one who should be ok running an npm install. If we make that explicit in our docs (I think we already have, in @panorama/toolkit and in panorama-template, I think our bases are covered.

That means that #10 is all we really need to aim for.

Going the npm route means also that we don't have to worry about the upstream deps confusion you mention -- npm will handle this if we get our build right.

ericsoco commented 8 years ago

Re: peerDependencies, yeah, it's annoying to have to run npm install twice, but peerDependencies theoretically allows us to avoid duplicate package versions in a @panorama/toolkit consumer. I'm still leaning toward peerDependencies because a) I don't like the extra footprint of dependencies being installed in projects that don't use all of them ( / all of the components), and b) because devDependencies will leave out required libs in an npm install scenario, as you describe above.

ericsoco commented 8 years ago

@mojodna have you seen @sconnelley's work here? I think he's moving toward what I describe above / what you are talking about in #10. @sconnelley correct me if I'm wrong / missed anything.

mojodna commented 8 years ago

I'm not sure that supporting inclusion via Githubissues.

  • Githubissues is a development platform for aggregating issues.