Yet another issue about how many sets of files to ship

I’m sorry, I can’t let go of this. One last time:

We should ship an iter-tools-es library which contains sources which are only transpiled down to the level of the most current ecmascript specification that is at least implemented in node. This code will be used in applications which transpile their dependencies to the desired level, or are able to rely on being run in a current node version. The main iter-tools library will be as it is now, though I’d say it wouldn’t be out of line to remove the non-es5 files eventually.

I’ll do the work on the build to make it happen.

[conartist6]

Actually though I think jest should work fine. It’s in node, and it can run any code that node knows how to execute. They reason it would be breaking is that it will always run the code through a transpiler first. It needs to do this to convert imports/exports into something node can understand.

When we don’t pre-transpile at all, that transpiler will choke if the appropriate sytnax isn’t supported. In this case node is more permissive than babel’s baseline. This is, btw, why web users who transpile deps do not (currently) want to import the es2018 files, and won’t until the current draft language spec becomes published. We can fix this if we cause jest to own the transpilation itself, by just adding the @babel/plugin-syntax-async-generators plugin to the configuration jest uses to run the es2018 tests.

Now that I thought through that properly, I will fix it today.

[conartist6]

I mean jest is meant to do the transpilation step itself, which works better since then it has sourcemaps and everything. We have a rather strange jest setup where we transpile ahead of time.