Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple Load Paths #31

Open
leeavital opened this issue Sep 9, 2014 · 4 comments
Open

Multiple Load Paths #31

leeavital opened this issue Sep 9, 2014 · 4 comments

Comments

@leeavital
Copy link

Not sure how feasible this would be, but it would be really useful to be able to have multiple paths for modules. One use-case is if there is library code in one folder and application code in another. It's impossible to test application code that depends on library code.

@pkozlowski-opensource
Copy link
Member

@leeavital I'm kind of the same boat as you and I'm still wondering if this should be added or not...

Technically it would be rather easy to add support for multiple "root folders" from which modules can be loaded. Having said this there were number of things that were stopping me from doing so:

  • (the most important) it would make this karma plugin behaving differently as compared to the Node's load algorithm;
  • I couldn't think of the nice configuration API
  • I didn't need it bad enough

So, I'm not saying we shouldn't add it but I would love to have some more discussion on the topic before starting any implementation efforts. Thoughts?

@leeavital
Copy link
Author

  • How important is maintaining Node's loading algorithm? If the point is to emulate a browser, it's not unreasonable to that different modules live in different trees (/vendor, /app)
  • As for a configuration API, something as simple as having modulesRoot be an array instead of string could work (although nested directories might pose a problem.)
  • I don't need it that badly either. I've been using karma-commonjs-processor, which lets you do this (albeit with a lot of configuration.)

Anyway, I would be happy to work on this if it's something worth doing.

@jamesshore
Copy link
Contributor

@leeavital The main motivation for karma-commonjs was to allow testing of Browserified code without needing to run Browserify itself. (That's slow and messes up stack traces, or at least it used to). What does Browserify and other tools' support for multiple trees look like?

@leeavital
Copy link
Author

I can't say for browserify, as I've never used it myself.

Karma-commonjs-preprocessor allows you to register a function that rewrites a file name. So if you had a folder named vendor and a folder named application, you could write:

karmaCommonJs: { 
  options : { 
     pathReplace: function( path ){ return path.replace( /^(vendor|application)/, '') 
     } 
  } 
}

So modules registered in /vendor/a.js and /application/b.js, can be required as:

require('a'); 
require('b'); 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants