You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if there's a better place to ask this, but this repo/issues tracker seemed as good as any.
I have to admit to not having much experience playing with some of the popular AMD implementations. It's not clear from the spec how things like requirejs's config.path fit into the big picture. I guess there's some allowance in the AMD spec to allow implementations to have flexible means of resolving module references to actual modules.
I'd like to expand on this. I am currently more or less familiar with node.js's module search algorithm, which involves things like rooting through relevant node_module directories, looking for relevant package.json files, etc. I would actually like to be able to use exactly this lookup scheme in AMD.
A little more; it needs to also work with "built" AMD runtimes like almond.
I don't necessarily want to "bake this into" an AMD implementation; I would prefer it to be a pluggable strategy that I can provide to AMD before it's gears start grinding away.
Not sure how closely related this is - it might be the answer to my feature request - is to provide a hookable function like node's require.resolve() - this is the only reference I could easily find to this function. The basic idea is to allow someone else to provide the name/module lookup, presumably given the 1) module executing the require(), 2) the string value of the module being require()d.
Perhaps there's some other way of accomplishing this.
My use case here is to be able to take a directory full of js files being used in node, and be able to run them unchanged, in the same way, as node, but using AMD. I'm willing to pay a price of creating some "fake" modules for directories, package.json file contents, etc, to make this happen. And again, end of the day, and all I really care about anyway, is being able to run this with a "built" runtime like almond.
The text was updated successfully, but these errors were encountered:
Since this is a higher level question, and it is being discussed on the email list and it seems difficult to get notifications of new issues on this list, let's close this issue for now and as the above discussion thread has more concrete tasks we can create issues for them as needed.
Not sure if there's a better place to ask this, but this repo/issues tracker seemed as good as any.
I have to admit to not having much experience playing with some of the popular AMD implementations. It's not clear from the spec how things like requirejs's
config.path
fit into the big picture. I guess there's some allowance in the AMD spec to allow implementations to have flexible means of resolving module references to actual modules.I'd like to expand on this. I am currently more or less familiar with node.js's module search algorithm, which involves things like rooting through relevant
node_module
directories, looking for relevantpackage.json
files, etc. I would actually like to be able to use exactly this lookup scheme in AMD.A little more; it needs to also work with "built" AMD runtimes like almond.
I don't necessarily want to "bake this into" an AMD implementation; I would prefer it to be a pluggable strategy that I can provide to AMD before it's gears start grinding away.
Not sure how closely related this is - it might be the answer to my feature request - is to provide a hookable function like node's
require.resolve()
- this is the only reference I could easily find to this function. The basic idea is to allow someone else to provide the name/module lookup, presumably given the 1) module executing therequire()
, 2) the string value of the module beingrequire()
d.Perhaps there's some other way of accomplishing this.
My use case here is to be able to take a directory full of js files being used in node, and be able to run them unchanged, in the same way, as node, but using AMD. I'm willing to pay a price of creating some "fake" modules for directories, package.json file contents, etc, to make this happen. And again, end of the day, and all I really care about anyway, is being able to run this with a "built" runtime like almond.
The text was updated successfully, but these errors were encountered: