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? >>> >
