Managing test dependencies with Volo

[Patrick van Kann]

Hi there,

I had a search on the archives and I don't think this has been asked previously. Sorry if I missed something!

I'd like to split my project up so that main and test source files and libraries are separated. For example my test libraries like Jasmine and the unit tests would go in the src/test/js folder, where the main JavaScript files and libraries would reside under src/main/js.

It seems like currently this would not be possible with Volo which manages libraries in a single location. I'm wondering what the best solution would be:

1) Not structure my project this way - this would be a shame, as it makes it easier to keep the built web project free from test artifacts. But if there's a better way I'm open to it!
2) Have two separate volo "domains" one in src/main and the other in src/test, each with their own volofile and package.json. This would work but it seems better to have a single package.json at the root.

From my brief research (http://jspkg.com/package_json), the package spec has the concept of testDependencies in addition to dependencies, devDependencies and optionalDependencies, which could be a way of defining these and managing them with volo in a single config. Is this something planned for the future?

Many thanks in advance,

Patrick

[James Burke]

I generally view dependency install with volo as getting dependencies
for an end project that just consumes them. Many cases the dependency
is just a single JS file.

The case you describe is where you are consuming dependencies to just
do tests and such, but just want to broadcast a different set of
dependencies for people that just want to use your code.

My first thought is that the #2 option makes sense, keeping test
dependencies in the test folder with its own package.json and the top
level package.json for broadcasting the actual dependencies to run the
library during runtime. This may work better too since I believe where
you want to install the test dependencies would be different than
where dependencies would be installed for the runtime library.

However, if it makes sense to include support for devDependencies or
testDependencies then we can look at that. One of the differences with
something like node/npm, the path layout is generally different for
front end projects, and precise paths matter -- the nested
node_modules approach does not work for front end projects.

So my main concern with supporting something like a devDependencies or
testDependencies is what the expectation on where those dependencies
would get installed in the project. That seems to be the issue to sort
out first.

James

[Patrick van Kann]

Hi James,

Thanks for responding - and also for Require, Almond, Volo, etc... the list is long!

I think I'll go with separate package.json files.

I did give some thought to how it could work with a single Volo config - I guess it would mean an addition to the package.json something like:

{
  "amd": {},
  "volo": {
    "baseUrl": "src/main/www/js/lib",
    "testBaseUrl": "src/test/www/js/lib",
    "dependencies": {
      "jquery": "github:jquery/jquery/1.7.2"
    },
    "testDependencies": {
      "jasmine": "github:jasmine/jasmine/1.x.y"
    }
  }
}

But it's hard to see this as a high priority and I'm guessing no other users have mentioned it before.

Cheers,

Patrick