tag:blogger.com,1999:blog-34454975.post6016534485097357817..comments2023-06-28T16:58:41.189+02:00Comments on Web Reflection: The node.js Relative Path CaseAndrea Giammarchihttp://www.blogger.com/profile/16277820774810688474noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-34454975.post-14796570498038859532013-06-05T04:52:57.971+02:002013-06-05T04:52:57.971+02:00another use case: require()ing a whole file tree (...another use case: require()ing a whole file tree (http://npm.im/require-tree), currently you need (__dirname + '/path'). Ricardo Tomasihttps://www.blogger.com/profile/00343846728973899375noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-42742422962223599232013-06-03T19:36:34.448+02:002013-06-03T19:36:34.448+02:00I actually think that not having it built-in (e.g ...I actually think that <i>not</i> having it built-in (e.g with <i>exportOnce</i>), but having it possible imperatively, <i>is</i> the simpler and thereby cleaner solution.<br /><br />Otherwise to solve the other side of what <a href="https://github.com/moll/node-require-guard" rel="nofollow">Require Guard</a> does in a similar vein would need an <i>exportTrulyForever</i> to match <i>exportOnce</i> and that'll get quite messy.<br /><br />The current common way to get a fresh closed over function sounds elegant enough — to have the caller invoke the exported function and to return a new function from there. Depending on requirers is something you and I only seldom need. :)Andri Möllhttps://www.blogger.com/profile/14549775032829968568noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-13049627653333790812013-06-03T19:21:42.295+02:002013-06-03T19:21:42.295+02:00I think in some case dropped cache can be a proper...I think in some case dropped cache can be a proper foot-gun as @izs said bot for these 2 cases, and probably others, is like: if you know what you are doing there's no harm.<br /><br />I see this situation the equivalent of "stateless functions" VS "scope dependent closures" where first one could be easily serialized and deserialized without problems about the outer scope since independent.<br /><br />In such case, it could be meaningful to <i>exportOnce</i> or something similar in order to flag the current module as "do not ever even bother caching it" which is basically what we both need, no matter what we do after that :)<br /><br />This would be a cleaner solution, until that, I am actually happy that we can do this at runtime.Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-38898565765291367782013-06-03T18:55:25.410+02:002013-06-03T18:55:25.410+02:00No particular reason to prefer module.id other tha...No particular reason to prefer <i>module.id</i> other than possibly slightly better abstraction, but Node's lib/module.js itself quite freely uses paths, so...<br /><br />Regarding having it in core, there's <a href="https://github.com/joyent/node/issues/3285" rel="nofollow">Issue #3285: expose a module.resolve method, or require.resolve(path, startPath)</a>.Andri Möllhttps://www.blogger.com/profile/14549775032829968568noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-1635980565774521822013-06-03T18:44:34.218+02:002013-06-03T18:44:34.218+02:00nice :) ... this means there are at least two case...nice :) ... this means there are at least two cases where such technique is needed .... and I believe more.<br /><br />@izs said that without use cases it does not make sense to provide the ability to have such relative resolution ... well, let's see if somebody else has more cases.<br /><br />One question though: I've used <i>__filename</i> instead of <i>module.id</i>, any reaso you would prefer the latter one?Andrea Giammarchihttps://www.blogger.com/profile/16277820774810688474noreply@blogger.comtag:blogger.com,1999:blog-34454975.post-42077514920704296162013-06-02T09:49:08.455+02:002013-06-02T09:49:08.455+02:00It's funny as I recently solved the exact oppo...It's funny as I recently solved the exact opposite problem — of <b>preventing specific file reloads</b> by Node.js test runners and other reloaders to get <b>slow initialization code to run only once</b>.<br /><br />In the vein of old #include guards and #pragma once's, named it <a href="https://github.com/moll/node-require-guard" rel="nofollow">Require Guard</a> (<a href="https://github.com/moll/node-require-guard" rel="nofollow">https://github.com/moll/node-require-guard</a>).<br /><br />And just like your require-updated, with irony, it removes itself from the require cache. ^_^Andri Möllhttps://www.blogger.com/profile/14549775032829968568noreply@blogger.com