Configurable loaders

[briandipalma]

Configurable loaders

[amavisca]

I'm thinking it'd make more sense to enable something like this as a command line argument.

I'd be happy to take a look at a pull request for this - but can we get away with something similar with just callbacks instead of promises?

[briandipalma]

I'm thinking it'd make more sense to enable something like this as a command line argument.

For people who write code in ES6/TypeScript/PureScript/CoffeeScript etc it would mean they'd always have to use this command line argument to load their tests. Would it not be easier to allow them to just add it to the configuration file?

If they add their loader it will be used if nothing is there it's just the default require(file) loading.

I'd be happy to take a look at a pull request for this - but can we get away with something similar with just callbacks instead of promises?

I'm not sure what advantage there is in just using callbacks other then fewer dependencies used. Promise.all would make waiting for many files to async load fairly easy, especially as Promises are the standard way to wait for async one-off operations now in JS.

Actually the PRs I've made would have been unnecessary if this package had used some of the other popular node packages out there, minimist for CLI parsing or mkdirp for making directories for example.

[amavisca]

The pull request clears things up for me. I'm not sure of my stance on this module loading specs that are not just plain ready-to-go JavaScript. That might be the responsibility of different test runners. Let me think this over some more.

Your PRs would have been unnecessary if we were using something like minimist. I'm not opposed to the idea of adding something for command line parsing. We were originally using https://github.com/tj/commander.js but it had some drawbacks that we didn't like so we stripped it out.

[briandipalma]

I'm not sure of my stance on this module loading specs that are not just plain ready-to-go JavaScript.

Well they have to be compiled down to ES5 for the tests to run so I don't see how it would affect Jasmine, I've tested this change in a project where I'm trying to stick to ES6 for the code and tests and it's working great so far. Really smooth and the loader is quite simple. It's totally transparent that the code is compiled on the fly.

That might be the responsibility of different test runners.

Jest (which wraps Jasmine) does have something like this loading functionality but I don't see why the Jasmine CLI tool can't do this itself. It's fairly straightforward functionality and probably going to become quite common in the future as code migrates from ES5 to ES6.

I used to use commander but have moved to minimist because there is rarely a need for anything more complex. I might be experimenting some more with the Jasmine CLI so if I have a need to change anything I might look into some minor refactoring.

[briandipalma]

Just as an explaination for why I'm trying to stick to ES6 code, we are still supporting JS code written 8 years ago for large scale applications and it's reasonable to assume that code written now for web applications will need to be supported in 8 years from now.

It's also reasonable to assume that by that timeframe the code we (and most other JS devs) will write will be in ES6+ so this would mean our ES5 codebase would be using older idoms and a more verbose coding style. It's the sort of code that might not receive much attention or would be prone to tech debt.

I realise these aren't normal use cases, I doubt most JS lives as long as our apps but it's the reality we have to live with targetting enterprise customers. Hence it would be better all round if we can write in ES6 as soon as possible to reduce the longer term cost of upgrading JS code.

[slackersoft]

Jasmine's general goal with respect to dependencies is not to have any runtime dependencies so users of jasmine don't have to worry about getting/needing extra libraries installed just so they can test with jasmine. We can let it slide a bit more in an environment-specific binding library like jasmine-npm. This desire, and the fact that commander wasn't doing quite what we needed is why it got removed.

I'm not a big node guy, but I'd be curious what we think minimist would supply such that you wouldn't have needed to send some of the PRs you did.

[briandipalma]

They are minor bugs tbh but minimist shows in its documentation that you should drop the first two CLI arguments before feeding it the rest of the CLI arguments.

var argv = require('minimist')(process.argv.slice(2));
console.dir(argv);

That's all I did in this PR, along with some minor clean up. mkdirp should have taken care of path separators for you making this PR disappear. Given these issues are fixed now I don't feel there is much need for them.

Tbh I've also stopped using commander.

[amavisca]

We don't like the idea of pulling in a promise library when a promise standard doesn't exist in stable versions of node yet.

We'd be interested in supporting custom loaders but we'd like to be handed a synchronous function to be a replacement to require. This leaves resolving promises/dealing with async up to the consumer.

[briandipalma]

It appears as if 6to5 has support for testing there is no need for custom loader support.