Guys, check https://github.com/medikoo/find-requires
-- Mariusz Nowak https://github.com/medikoo http://twitter.com/medikoo On Tuesday, March 27, 2012 10:26:32 AM UTC+2, Bruno Jouhier wrote: > > Same way you do it: regexp > > On Monday, March 26, 2012 9:49:28 PM UTC+2, meelash wrote: >> >> btw, bruno, how do you do the dependency analysis? A full parser? >> >> On Monday, March 26, 2012 12:01:41 AM UTC-7, Bruno Jouhier wrote: >>> >>> I have a similar thing. Not fully packaged but I published it a while >>> ago: https://github.com/Sage/streamline-require >>> >>> It analyzes the dependencies server side and supports both synchronous >>> and asynchonous requires. Like yours, it returns the entire dependency >>> graph in one shot. So the client gets everything it needs in one roundtrip. >>> It also monitors changes to the source tree and returns a 304 if the >>> browser has an up-to-date version. >>> >>> There is one further refinement: when you request additional module >>> asynchronously, the client sends to the server the list of modules that it >>> had requested before and the server computed the list of dependencies of >>> the new modules as well as the list of dependencies of the modules that had >>> been requested before and it sends back to the client a single response >>> with the modules of the first list that are not in the second list. So, if >>> the client had gotten A, B, C, D, E, F in a first require and requests G >>> which requires B, C, and H, the server only returns G and H to the client. >>> I the client then requests I which requires C, F and H and J, the server >>> returns only I and J. >>> >>> Overall, this is extremely fast. >>> >>> I was doing the dependency analysis client side before and loading the >>> modules one by one. Terrible in comparison. >>> >>> Bruno >>> >>> On Sunday, March 25, 2012 1:04:52 AM UTC+1, meelash wrote: >>>> >>>> tl;dr - Client-side require with a server-side component that caches >>>> dependencies, bundles them, and caches the bundles. Need feedback on >>>> the concept, syntax. Need suggestions/contributions on implementation. >>>> Although, this works for me, it is almost just a proof-of-concept, >>>> needs work. >>>> >>>> >>>> As part of a project I'm working on, I spent a few hours writing a >>>> little client-side module loader with a server-side component enabling >>>> what I think is a pretty neat meaning to CommonJS module syntax. This >>>> morning I pulled it out of the rest of my project and attempted to >>>> package it in a useful way for others to use. >>>> >>>> The basic idea is this- in your client-side code, you can use require >>>> in either a "synchronous" or asynchronous fashion- >>>> module1 = require('some/path.js'); >>>> require('some/other/path.js', function(err,result){module2 = >>>> result;}); >>>> >>>> An asynchronous require makes a call to the server component to get >>>> the file in question, but before returning the file, the server parses >>>> it, finds all the synchronous require calls, loads those files as well >>>> and returning the whole thing as a package. That way, when the >>>> original file that was asynchronously loaded is executed and comes to >>>> one of those synchronous require calls, that file is already there, >>>> and the require is actually synchronous. >>>> >>>> At this point, maybe this screencast demo will help to clarify how it >>>> works: >>>> http://screencast.com/t/nOU53BRYUAX<http://screencast.com/t/nOU53BRYUAX> >>>> >>>> Put another way: >>>> If I async require fileA, and fileA has synchronous dependencies on >>>> fileB, and fileC, and an asynchronous dependency on fileD, the server- >>>> side component will return (in a single "bundle") and keep in memory >>>> fileA, fileB, and fileC, not fileD, and it will execute fileA. >>>> The client-side also separates fetching the files and eval'ing them >>>> (the method of getting files is xhr+eval). So, let's say fileA has >>>> require('fileB'); that executes when the file is parsed and executed >>>> on the client, but require('fileC') is inside a function somewhere. >>>> Then fileA will first be eval'ed, then fileB when it comes across >>>> that, and the text of fileC will just be in memory, not eval'ed until >>>> that function is called or some other require to it is called by any >>>> other part of the program. >>>> >>>> Another example- >>>> fileA has dependencies fileB, fileC, fileD, fileE, fileF >>>> fileG has dependencies fileC, fileE, fileH >>>> >>>> When I call require('fileA', function(err,result){return 'yay';});, >>>> the module loader will load fileA, fileB, fileC, fileD, fileE, and >>>> fileF all in a single bundle. >>>> If I, after that, call require('fileG', function(err,result){return >>>> 'yay';});, the module loader will only load fileG and fileH! >>>> >>>> Hopefully, that's clear.... >>>> >>>> The advantages- >>>> Being aware of the difference in synchronous and asynchronous require >>>> in your client-side code make it extremely natural to break all your >>>> client-side code into small reusable chunks- there is no penalty and >>>> you don't have to "optimize" later by deciding what to package >>>> together and what to package separately. >>>> Handling dependencies becomes nothing. You don't have to think about >>>> it. >>>> The server can have a "deployment" mode, where it caches what the >>>> dependencies of a file are and doesn't ever need to parse that file >>>> again. >>>> In "deployment" mode, the server can also cache bundles of multiple >>>> files that are requested together, so when another client requests >>>> that same bundle, it is already in memory. >>>> >>>> To sum up: >>>> xhr+eval-when-necessary client-side module loader >>>> both synchronous-ish and asynchronous require in your client side-code >>>> --the synchronous require is actually a command to the server-side >>>> component to bundle >>>> server-side component >>>> --parses for dependencies and bundles them together >>>> --can cache dependency parsing results and whole bundles >>>> >>>> >>>> So- thoughts? Is this a horrible idea? Are there some gotchas that I'm >>>> missing? >>>> >>>> Specific advice needed- >>>> • How to package this in a way that it can be easily used in other >>>> projects? How can I make it integrate seamlessly with existing servers >>>> and make it compatible with different transport mechanisms? >>>> • How to handle path resolution? >>>> • Suggestions for licensing? >>>> • Suggestions for a name- (Mundlejs is a portmanteau of Module and >>>> Bundle- didn't really think long about it) >>>> >>>> Things that need to be (properly)implemented: >>>> • server-side "parsing" is just a brittle regexp right now: >>>> (line.match /require\('(.*)'\)/) >>>> • neither type of server-side caching is implemented (pretty easy to >>>> do) >>>> • uniquely identify clients and keep the server away of what modules >>>> they already have, so we can just send the diff of cached modules- >>>> currently, I'm sending the entire list of already cached modules with >>>> every xhr call, so the server doesn't load a dependency twice. >>>> • proper compatibility with module specifications (i.e. CommonJS)- >>>> right now, it's just require and module.exports >>>> >>>> >>>> Code is available here: >>>> https://github.com/meelash/Mundlejs<https://github.com/meelash/Mundlejs> >>>> To test it: >>>> from Mundlejs/tests/, run >>>> node server.js >>>> visit http://127.0.0.1:1337/ and open your browser console. >>> >>> -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
