Google Groups

Re: [node-dev] proposal for new field in package.json (shims)

Mariusz Nowak May 6, 2012 3:07 AM
Posted in group: nodejs-dev
I agree with Marco, it's rather Browserify (or any other similar bundler) part to make use of that section, just for Node.js or npm it's just extra baggage they don't need.

Other important thing, shim settings should rather be configured per module not per package. Modules across package may have different shim dependencies and in your project you may use just some modules from a package.

Mariusz Nowak

On Friday, May 4, 2012 11:30:39 PM UTC+2, Marco Rogers 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.


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 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 <> 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 <> 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 <> 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 ( and 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 ( has a working implementation. I hope other bundling tools jump on board :)
>>>> Thoughts? Terrible? Useless? Wonderful?