Karma: Support for async/await in karma code
What do you thinks about using async/await in our code. It is natively supported from Node 8, but Node 6 is now in maintenance, and it's end of life is planned to April 2019.
We can consider remove karma support for Node 6 now, or adapt puppeteer solution.
lusarz
All 12 comments
Personally I would like to see the node-v4-level updates completed first, like var -> const and use of classes. Adopting node 6 now could force us to support two versions which would not be practical. I could see switching to node 6 once we are closer to April.
Somewhat related but perhaps more difficult: a way to support existing plugins but also allow asynchronous plugins would be cool.
johnjbarton
on 1 Oct 2018
Ok, it sounds good to me
lusarz
on 1 Oct 2018
@johnjbarton, if one wanted to work on the node v4 level updates, is there anywhere you would recommend to start?
jniles
on 1 Dec 2018
We're actually pretty close to the finish line. Look for files with var that are not /client (these are files the ship to the browser).
johnjbarton
on 1 Dec 2018
@johnjbarton, am I right in thinking that both /common and /context are also shipped to the client? It looks like both are processed by browserify in the build process.
jniles
on 1 Dec 2018
Looks like @lusarz got them all huh?
johnjbarton
on 1 Dec 2018
@johnjbarton yeah, now I'm waiting for green light to introduce async/await ;)
@jniles Some times ago I've did some research about possibility to replace var into const/let in /common and /context, but varify didn't wanted to work for me.
lusarz
on 1 Dec 2018
If we add async/await and thus create a breaking 4.x version, what will be our plan if we have to create another 3.x release (say a security issue or compat with some dep release)? Doesn't have to be a great option but I'd like to know the cost of the extreme case.
johnjbarton
on 3 Dec 2018
What about forcing users to use node >=8 and forget about karma releases with node 6 support at all ? Are there some use cases when it may not be possible (migrating to node >=8) ?
lusarz
on 3 Dec 2018
Yes, I assumed we would drop node v6. So our story could be "Sorry, if you want to use node v6 after 3.1.2, you have to fork the source". I just want to make a clear decision, not an accident and no implied support for two versions at the same time.
johnjbarton
on 4 Dec 2018
Yes, I agree with that.
lusarz
on 4 Dec 2018
v3.1.4 seems stable, let's call that the last node 6 version and move on to v4 w/node 8 and async.
johnjbarton
on 28 Dec 2018
Related issues
IgorMinar
路
5Comments
VinishaDsouza
路
3Comments
TKTheTechie
路
4Comments
sneakyfildy
路
3Comments
ebacka
路
3Comments
Most helpful comment
Personally I would like to see the node-v4-level updates completed first, like
var->constand use of classes. Adopting node 6 now could force us to support two versions which would not be practical. I could see switching to node 6 once we are closer to April.Somewhat related but perhaps more difficult: a way to support existing plugins but also allow asynchronous plugins would be cool.