Comments (9)
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?
from jasmine-npm.
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.
from jasmine-npm.
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.
from jasmine-npm.
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.
from jasmine-npm.
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.
from jasmine-npm.
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.
from jasmine-npm.
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.
from jasmine-npm.
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.
from jasmine-npm.
It appears as if 6to5 has support for testing there is no need for custom loader support.
from jasmine-npm.
Related Issues (20)
- jasmine flags, oneFailurePerSpec and stopSpecOnExpectationFailure don't work well HOT 2
- RFC: Well-defined public API HOT 1
- Can't get Jasmine 4 to support .jsx files HOT 7
- Failed to load reporter module jasmine 4.x HOT 1
- Jasmine loads test dependency as CommonJS module instead of ESM HOT 2
- Export Loader HOT 2
- getting an error jasmine.getEnv is not a function HOT 2
- Unable to find specs when using [email protected] HOT 2
- Consider using child_process.fork() to parallelize Jasmine runs HOT 28
- Jasmine 4 ES Modules / Dynamic Import Doesn't Work with Paths that Have Encoded Slashes HOT 4
- jasmine --helper flag broken following addHelperFiles() removal
- --reporter does not work with namespaced modules HOT 4
- Feature Request: Allow re-running test suites without restarting HOT 2
- Package subpath './lib/command.js' is not defined by "exports" using jasmine-xml-reporter HOT 1
- Vulnerabilities found on latest version of Jasmine(4.6.0) HOT 1
- Problem excluding files HOT 4
- Project base dirs containing special Glob syntax don't work HOT 1
- Regression in jasmine 5: settings bleed over to next `Jasmine` instance HOT 4
- `--require` fails with `runner.addRequires is not a function` in 5.x HOT 1
- Add a `--verbose` flag HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jasmine-npm.