I don't think you and I are disagreeing much. I'm suggesting that you get
something working and then build community support for it. The reason other
projects would accept a pull request from you for this is because it's
useful and they see other people rallying behind the idea.
The only reason I mention npm is that it's arguably the most important
consumer of package.json and you shouldn't do anything to screw up the
conventions already in place. Other than that, it's a non-issue.
As for the bikeshedding, I was trying to make a point. Go with whatever you
want, but if you want consensus, you're gonna have to deal with other
people's opinions. Getting something working first is a good way to head
that off.
Also, just because you can't think of another environment doesn't mean
there aren't any. I can think of a few off the top of my head: Desktop
environments like Adobe AIR, Browser extension environments (which are a
huge pain in the ass), mobile app environments (e.g. Cordova). Right now it
may seem like YAGNI, but it doesn't take much to allow some flexibility for
the (near) future. JS is everywhere now.
:Marco
On Friday, May 4, 2012 3:03:01 PM UTC-7, Roman Shtylman wrote:
>
> I don't see what npm has to do with this. Package.json is the goto
> place for module information (not just for npm). I think creating a
> "de facto" standard would be very presumptuous of me. Why would
> projects like socket.io or browserify accept my random patches to add
> things to their package.json file when anyone else could come along
> and decide they want to call it something else? I think it would be
> very who of us to not only decide on something we can encourage
> package authors to use (and thus accept pull requests for) but also
> encourage this behavior. It would be quite remiss to not realize that
> all of this js code people are writing has applications for server and
> client and provide reasonable and well documented ways to make that
> happen.
>
> While I do love me some good bike shedding (I would like mine yellow
> please), I can't help but think the example just complicates the
> matter. I can't think of any other "environments" currently besides
> client and server (but am ready to be wrong on this). Also, the word
> shim was chosen since it succinctly conveys the meaning of the action,
> but again if others feel very strongly on the matter then another word
> would do just fine.
>
> I realize I could have just pushed anything out there, but the goal
> with discussing this is to get community support behind a reasonable
> way to do it so that our package.json files don't become bloated
> messes. Like I said, server side js in a unique position here and I
> think we should capitalize on it ;)
>
> On Fri, May 4, 2012 at 5:30 PM, Marco Rogers <marco.rog...@gmail.com>
> wrote:
> > Yeah I was thinking this sounds like an important use case. But it's
> really
> > taking something that should be a configuration feature of browserify
> and
> > trying to make it a "spec". That's not bad, because it's not just
> browserify
> > that could use this. It's really for any component that wants to deliver
> > node modules to the client. And having a bunch of interested parties
> agree
> > on what that looks like would make more sense than everyone doing
> something
> > different. The problem with this is that deciding on the look of it
> invites
> > bikeshedding. For example :) ...
> >
> > I've always hated the term shim, and this could also be used for
> providing
> > multiple alias definitions for different environments. So I'd be
> interested
> > in something like this.
> >
> > aliases: {
> > browser: {
> > ws: "browser-ws"
> > }
> > , somethingElse: {
> > ...
> > }
> > }
> >
> > That said. I don't feel strongly about any of this. I agree with Isaac
> that
> > as long as you don't step on what are already "de facto" standards via
> npm,
> > then do what you like and get it working. Then other people can pick it
> up
> > and you'll have your own de facto standard.
> >
> > :Marco
> >
> > On Friday, May 4, 2012 11:19:16 AM UTC-7, Isaac Schlueter wrote:
> >>
> >> Any field mentioned in `npm help json`, or starting with a _, is
> >> npm's, and you may not have it.
> >>
> >> That aside, if you want to add arbitrary fields to your package.json
> >> files, then feel free. It's very rare that we add new package.json
> >> features to npm these days (peerDependencies is on the todo list, but
> >> I can't think of any others), and I usually check
> >> http://registry.npmjs.org/-/fields before adding any others, to make
> >> sure they're not already in use.
> >>
> >> "shims" sounds like a fine and useful feature for modules like
> >> browserify and others, but npm will not do anything with it. "I want
> >> to use module X but I want to call it Y" is not something that I'm
> >> interested in supporting.
> >>
> >>
> >> On Fri, May 4, 2012 at 10:25 AM, Andreas Richter <richt...@gmail.com>
> >> wrote:
> >> > I was thinking if something like mongoose being shimmed. Your example
> >> > makes sense. A shim for a database module is very much up to the
> >> > system architecture. Shimming something like crypto really makes
> sense
> >> > in your design. So i agree to lean toward it being a good idea. Just
> >> > needs some exception (maybe plugin ability.)
> >> > Andy
> >> >
> >> > Sent from my iPhone
> >> >
> >> > On May 4, 2012, at 11:37 AM, Roman Shtylman <shtyl...@gmail.com>
> wrote:
> >> >
> >> >>
> >> >> I think specifying a particular shim in the package.json file is
> useful
> >> >> since more eyeballs will result in better cross browser support and
> testing
> >> >> for the particular shim. If you have to write the shim code
> yourself, you
> >> >> need to know more inner workings about the module.
> >> >>
> >> >> You would still be able to override those shims with your own if you
> >> >> desired but at least this way it would have a better chance of
> working out
> >> >> of the box.
> >> >>
> >> >> On May 4, 2012, at 11:26 AM, Andreas Richter wrote:
> >> >>
> >> >>> I like the idea but shouldn't the package.json just specify whether
> a
> >> >>> client shim is needed or not? It seems too inflexible if you
> require a
> >> >>> specify shim. The shim or not shim would also depend on the
> platform,
> >> >>> browser or usage. Might be a can-o-worms...
> >> >>> Andy
> >> >>>
> >> >>> Sent from my iPhone
> >> >>>
> >> >>> On May 4, 2012, at 10:54 AM, Roman Shtylman <shtyl...@gmail.com>
> >> >>> wrote:
> >> >>>
> >> >>>> Since node.js code is javascript, many node.js modules have the
> >> >>>> useful property of being able to be run on client and server side.
> Using
> >> >>>> tools like browserify (https://github.com/substack/node-browserify)
> and
> >> >>>> script (https://github.com/shtylman/node-script) you can easily
> package
> >> >>>> node.js modules for the browser.
> >> >>>>
> >> >>>> However, there is generally one hurdle when doing this. Some
> modules
> >> >>>> depend on code or third party modules that are server specific.
> When
> >> >>>> bundling (act of preparing for the browser) these modules it would
> be wrong
> >> >>>> to include these server only modules. Instead, the bundler tool
> needs to be
> >> >>>> able to shim out those 3rd party modules in favor of alternate
> code which
> >> >>>> replicates the functionality in the browser. Currently tools like
> browserify
> >> >>>> and script allow you to do this manually in your code. This is
> error prone
> >> >>>> as you have to know the dependencies for any thrid party modules
> you use and
> >> >>>> track if you need to shim them out or not. Instead I propose that
> we
> >> >>>> "standardize" and put this information into the package.json file
> so that
> >> >>>> any such bundling tool (and other tools) will know that when the
> code is
> >> >>>> bound for a browser, certain modules should be replaced.
> >> >>>>
> >> >>>> Imagine a package.json with the following dependencies:
> >> >>>>
> >> >>>> "dependencies": {
> >> >>>> "ws": "x.x.x",
> >> >>>> "some_native_module": "x.x.x",
> >> >>>> "pure_js_module": "x.x.x"
> >> >>>> }
> >> >>>>
> >> >>>> The module author would now be able to provide the following
> >> >>>> additional section (if needed):
> >> >>>>
> >> >>>> "shims": {
> >> >>>> "ws": "./shims/ws.js",
> >> >>>> "some_native_module": "./shims/something.js"
> >> >>>> }
> >> >>>>
> >> >>>> This would be entirely optional but it would allow modules that
> have
> >> >>>> no technical impediment to working in the client and server to be
> bundled
> >> >>>> easier. I think this would be a useful addition since all the code
> is
> >> >>>> javascript and we as module authors can benefit and help others by
> >> >>>> recognizing and making it easier to use all of this new code in
> both
> >> >>>> environments.
> >> >>>>
> >> >>>> If you want to try this out, the wip-shim branch for script
> >> >>>> (https://github.com/shtylman/node-script/commits/wip-shim) has a
> working
> >> >>>> implementation. I hope other bundling tools jump on board :)
> >> >>>>
> >> >>>> Thoughts? Terrible? Useless? Wonderful?
> >> >>>>
> >> >>
>
