why? because, writing test code like this is much better (Eventually we can drop large chunks of ember-testing)
example app: https://github.com/stefanpenner/ember-jobs

app code isn't to bad either:


If there is any busywork around this that you'd like to pass off, I'm interested!
@trabus we really need jshint to understand this syntax, even if it is a fork of jshint until its ready. There are several PR's that implement it.
Now as for the automatic polyfil inclusion, I think we should come up with an RFC to re-think how ember-cli composes apps and addons so we can better accomplish this. I have some ideas here, just having a hard time coalescing my thoughts. Tomorrow I'm working with @chadhietala on transitioning to npm (dropping bower) and I think it has some overlapping needs.
I will have my thoughts in RFC form by tomorrow night or wednesday morning. At which time I would love thoughts and feedback. If you have ideas to explore related to this before then, please don't hesitate. The more input later this week we can get the better.
Finally, the scheduler for RSVP shouldn't be to tricky, but will require some RSVP internals knowledge, that I can share if you are interested in pursuing it.
Has any thought been given to using ESLint rather than JSHint? It supports this syntax no-problem, and is much more flexible / customizable.
Has any thought been given to using ESLint rather than JSHint? It supports this syntax no-problem, and is much more flexible / customizable.
Ya i've been tempted, if jshint doesn't catch up I will likely consider the switch.
I recently asked about async/await here: https://github.com/jshint/jshint/issues/1939#issuecomment-77899370 and the answer did not sound promising for anything to be done any time soon.
Also, JSHint is removing all of their code-style checks and telling people to use JSCS for them. Seems like it would be a lot easier (and faster?) to run one linter instead of two. Several of the options in the current ember-cli .jshintrc are deprecated:
Are all currently deprecated and will be removed in the next version of JSHint.
Also, JSHint is removing all of their code-style checks and telling people to use JSCS for them. Seems like it would be a lot easier (and faster?) to run one linter instead of two. Several of the options in the current ember-cli .jshintrc are deprecated:
camelcase
immed
newcap
noempty
quotmark
laxbreak
sub
Are all currently deprecated and will be removed in the next version of JSHint.
this seems like a good point to raise, but not in the context of this issue as it appears mostly unrelated.
Apologies. I'll create a separate issue for it.
I thought it tangentially related because if a new version of JSHint is needed for async/await, it will break the options listed above.
@IanVS I moved the Ember Inspector to ESLint to be able to use async/await: https://github.com/emberjs/ember-inspector/pull/340 (it's an ember-cli app)
Is this planned to be done any time soon? I'm using async/await on an express server using babel successfully and would really appreciate it if same pattern could be applied to client side code.
@mohamnag it is already possible, just not entirely automatic.
just add: https://github.com/stefanpenner/ember-jobs/blob/master/app/index.html#L20-L23 + https://github.com/stefanpenner/ember-jobs/blob/master/Brocfile.js#L7-L12
We are more or less waiting for async/await to hit stage 4 so that we know its not going to change, and libraries like JSHINT implement them. Once that happens we will likely make sure its more automatic the the above two stops.
thanks thats great news!
jshint folks are open to a PR, assuming someone wants to push one of them to completion, we can then begin making it trivial on our end.
Basically, I think we are going to make the switch to eslint and call it a day.
@Turbo87 your on-board with that correct?
Yes, that has also been my plan (RE: testing RFC).
In general yes, but there a still a few remaining pieces that are hardcoded to jshint which we need to address first
@Turbo87 is there a tracking issue?
I don't think so. Example of what I was talking about: https://github.com/ember-cli/ember-cli/pull/5895
The snippet from https://github.com/ember-cli/ember-cli/issues/3529#issuecomment-165030263 results in Unexpected token
given that RSVP polyfill isn't here yet, how do you guys would implement something like this without RSVP.all? or that isn't possible right now?. thanks
let details = await order.get('details');
return Ember.RSVP.all(details.map((detail) => detail.get('product')));
given that RSVP polyfill isn't here yet, how do you guys would implement something like this without RSVP.all? or that isn't possible right now?. thanks
I'm confused, RSVP is present in all ember apps.
sorry, I mean RSVP working with async/await. I would like to use it like await Ember.RSVP.all but it seems RSVP needs a PATCH for that, so, how do you guys would implement something like the example above without RSVP.all e.g (maybe await [Array of Promises], don't know)? or that isn't possible right now?.
let details = await order.get('details');
return Ember.RSVP.all(details.map((detail) => detail.get('product')));
@sescobb27 it should "just work" as RSVP.all returns a thenable, and await must "assimilate" all thennables.
@stefanpenner So, looking at your original comment, is this basically done, since jshint is on its way out anyway?
I'd love to start using async functions "officially" :grin:
@buschtoens jshint isn't out yet, so its not quite done (hopefully soon).
@stefanpenner Thanks for the insight. So, if I understand correctly, when I replace ember-cli-jshint with ember-cli-eslint I'd basically be good to go and everything should just work :tm: ?
@buschtoens more or less, yes
see https://github.com/ember-cli/ember-cli/issues/6501 for the JSHint -> ESLint replacement tracking issue
async/await works pretty well by now :)
Most helpful comment
Basically, I think we are going to make the switch to eslint and call it a day.
@Turbo87 your on-board with that correct?