Skip to content
This repository has been archived by the owner on Feb 6, 2020. It is now read-only.

add a requirejs example of using nap #5

Merged
merged 2 commits into from
Jan 16, 2014

Conversation

haggyj
Copy link
Contributor

@haggyj haggyj commented Jan 14, 2014

I added the simplest possible example of using the library in the context of RequireJS. I figured that coupling it to a particular standard made little sense for now so opted to just add an example for people to get started.

A few points came up now I'm more familiar with the library and might be worth having a think about...

  • Do we need both a lib and components directory? Any reason not just to specify a few more bower dependencies?
  • Should we check in the components directory? We're already doing this with lib but it might be because these libraries aren't core to nap.

@mstade
Copy link
Collaborator

mstade commented Jan 14, 2014

Dependencies on the web are a god damn mess. I'd say picking a strategy – any strategy – is better than being inconsistent. It doesn't matter if it's it bower-all-the-things, npm-all-the-things, check-in-all-the-things, or any other kind of strategy; there will always be contention so long as everyone is building their own package management system (or ignore them altogether.) Rather, I think the most important aspect is to be consistent, and provide some sort of docs on what choice was made. A package.json or whatever works fine in lieu of human docs, so long as that's the only one; multiple choice makes me cry.

@haggyj
Copy link
Contributor Author

haggyj commented Jan 14, 2014

Interestingly, even the twitter libraries have both a bower.json and a package.json - mostly because they use node for minification and distribution whereas they pull in local dependencies using bower - typeahead is one such example. 😡

Is it reasonable to expect that 'web' dependencies are fetched via bower and 'build' dependencies via npm? I'd say this is pretty normal for most bower type projects...

@mstade
Copy link
Collaborator

mstade commented Jan 14, 2014

Is it reasonable to expect that 'web' dependencies are fetched via bower and 'build' dependencies via npm? I'd say this is pretty normal for most bower type projects...

I think it's more a matter of let's-cover-all-the-bases than having some sort of meaningful rationale. @substack often says "NPM ALL THE THINGS" and I seem to remember @isaacs saying "can't see why not" or something to that effect, somewhere. There's also npm/npm#4321 in which a bunch of people are trying to figure out some of the kinks of npm-all-the-things (where, as far as I can tell, all-the-things really mostly means web things.)

Regardless of whether you think npm is a good or not (I'm like, meh – but that's a different story) it's hard to argue its relative success. It may well be that I'm not "in tune" with the cool kids, and that there's truly something that makes the npm/bower/whatever dichotomy valid, but I have found no evidence for it. Seems to me it mostly comes down to matters of taste in mechanics, rather than any fundamental reasons why there couldn't be a single manager. I reckon we'll converge, and my gut tells me that npm will "win" simply because it has more traction.

Regardless, I think my original advice of just-pick-a-strategy-and-be-consistent still valid, as there's seemingly no "correct" choice. No matter what you do, you'll end up possibly alienating some crowd that has their toolchain set up their way and they'll cry foul either way. As popular as npm is, there really is no de facto standard for package management. The module format mess likely owns part of the blame, but we'll still have this weird mix of options when ES6 modules come around. At least for some time.

You could of course just support all the popular options, and end up feeling like @mbostock:

So #d3js supports NPM, Bower, Browserify, Jam, jspm and Component for package management. (And AMD.) What a mess!

— Mike Bostock (@mbostock) January 14, 2014

And coincidentally (unless I missed a memo and today is moan-about-the-state-of-affairs-day) @jrburke posted this little gem on twitter today:

I like that front end apps have tradition of checking in deps to app repos. Avoids lots of problems. That should be kept going forward

— James Burke (@jrburke) January 14, 2014

(Btw, @mikeal has posted some insightful commentary on the topic of checking in dependencies.)

The only winning move, it would seem, is not to play the game. :o)

@@ -3,5 +3,6 @@
"version": "0.0.0",
"dependencies": {
"rhumb": "git://github.com/sammyt/rhumb.git"
, "requirejs": "git://github.com/jrburke/requirejs.git"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets drop this line. I think its sufficient to have the example without muddying the waters of which dependencies are "real" or not. Can avoid making any big decisions by using requirejs from a CDN for now

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

(Off topic – I was explaining to my father today about your propensity for deferring big decisions, how that makes you stay on point, and how I wish I could be more like that. Uncanny.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems legit. 👍

sammyt added a commit that referenced this pull request Jan 16, 2014
add a requirejs example of using nap
@sammyt sammyt merged commit 77e25ce into sammyt:master Jan 16, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants