Can't require a module with relative paths
slvnperron opened this issue · comments
Modules must be in node_modules and referenced using their name only. ex:
Works: require('jasmine')
Fails: require('./jasmine.js')
(See #22)
Is there a workaround for this issue?
This is a big problem for me right now, because it seems to mean that all the code for a task has to go in a single file (other than published npm dependencies), which makes it difficult to reuse code across multiple Lambda tasks.
There is an undocumented feature that is still being developed, but you can
include relative module with a + sign in front of the path. Please have a
look at the zipper.js file to see how that works internally, it's working
but not quite ready. There's been a PR recently on this too.
Sent from my Nexus
On Apr 2, 2015 09:20, "Jesse Skinner" notifications@github.com wrote:
Is there a workaround for this issue?
This is a big problem for me right now, because it seems to mean that all
the code for a task has to go in a single file (other than published npm
dependencies), which makes it difficult to reuse code across multiple
Lambda tasks.—
Reply to this email directly or view it on GitHub
#20 (comment).
Thanks! Seems like a fine approach, since we have to explicitly list other requirements as well. I'll try to get that working.
Ok the only way I can get it working is to create a folder called project_files and require dependencies from inside there. So on Lambda the function can require('./project_files/lib') but if I put it anywhere else (a different folder name), the requirement fails. Are you aware of this limitation? Or is there a way around it (yet)?
Yes that is right. The plan is to recreate the dependency path but this
won't work if you require files outside your function path (eg
../../file.js) . Any suggestion?
Sent from my Nexus
On Apr 2, 2015 09:50, "Jesse Skinner" notifications@github.com wrote:
Ok the only way I can get it working is to create a folder called
project_files and require dependencies from inside there. So on Lambda the
function can require('./project_files/lib') but if I put it anywhere else
(a different folder name), the requirement fails. Are you aware of this
limitation? Or is there a way around it (yet)?—
Reply to this email directly or view it on GitHub
#20 (comment).
Understood, yeah that's tricky.
Maybe it'd be simpler to implement if the dependencies have to be inside a project folder, where the entire folder contents get zipped up for Lambda. Then I could do something like -
/task/index.js
/task/lib/include.js
/task/lib/etc.js
/task/static/something.html
/run.js
So inside run.js, you could run the task like: lambda('./task', [], {name:'TASK'}) and have all the contents of the task folder get zipped up.
And then inside task/index.js you'd be able to do require('./lib/include') and the dependency should "just work" without needing to be declared or remapping any folder paths.
Thoughts?
We discussed it internally and the primary goal of lambdaws is to remove friction and make it easy for everyone to use it. We think it's really needed to support any relative path and recreate the whole dependencies tree.
So a dependency like ['../../folder1/1.js', '../2.js', './3.js'] would zip to something like:
- folder1/
-- 1.js - lambdaws/
-- index.js
-- 3.js - 2.js
Would that work? Could adding a trailing * to include the whole directory be even better? e.g. ['../folder1/*']
Yes I agree on allowing any path - that's how I expected it to work initially.
I think the least friction would be determining dependencies automagically, the way that Browserify and other tools are able to traverse the dependency tree. But that sounds like a lot of work to get running and to maintain.
But within the list of dependencies, which I think is a fair approach, then yes I think relative paths in the dependency list works well, and using glob matching in the paths would be really handy (eg. ['../images/**/*.jpg']).
@jesseskinner Thanks for the input. Is this something you would be interested working on?
By the way I like your YT videos
Hey thanks a lot!
Yep I'd be interested in helping with this. I've been reading through the code trying to understand how it all works.
@jesseskinner awesome! Please let me know if we can help or if there's anything you miss. You can also reach us on Gitter