Provide transpiled version/variant for Node < 4.6 about edtf.js

[inukshuk]

From all the features we use, generators are the only thing which require special treatment (e.g., if you use regenerator you'll have to include their runtime in your code, too).

I considered adding a Node version requirement to the package.json, to make sure that you can't install the package with anything less than Node 5 (or Node 4.6 which is probably fine) -- but that would make life hard for everyone who still wants to use it (or at least parts of it).

As you can see, all that is not an answer, but just my rationale. Of course it makes sense include (or offer separately) a transpiled version (preferrably with minimal extra dev dependencies and a npm prepublish script).

[inukshuk]

No, sorry, I haven't tested this on older Node versions. This library makes use of a number of ES6 features and ES5 compatibility was not a target for me.

Having said that, depending on what parts you actually need, transpiling should be relatively easy: probably generators are the only serious problem (and you don't need them for parsing). Glad to help out, but like I said, this is really intended for ES6.

[johanneswilm]

Yes, I have been working with ES6 onmy own projects since the start of the year myself and I am transpiling everything. Nevertheless, it took me some hours to figure out why my nodejs tests were throwing an error when everything looked fine in the browser. The help in the readme that tells me to use harmony flags had me work on it for another hour or so, until I figured out that none of the flags work. I thought that I should let you know here and others who run into the same issue will hopefully not spend half a day on this.

[inukshuk]

Ah, sorry about that, the language there could be clearer.

[johanneswilm]

Yeah, no worries.

One related thing: I think this is the first project I have come across where the ES2-15 is not transpiled to ES5 when publishing to npm [1]. That means that it behaves slightly different than other packages.

So if I set up testing in a repository that depends on this package, for example with ava [2], I have to ensure cross-compilation of ES2015 at three different levels:

• the test code (ava supports this out of the box)
• my code: there are easy setups that ensure that ava only gets code that has been run through babel.
• the imported edtf.js package: AFAICT, this is not covered by any of the standard setups. It also means that even though I cross-compile my package to ES5, it is still not directly usable by any ES5-only consumer because I depend on your package, unless I bundle a cross compiled version of your package with my package.

As far as I can tell, if one imports from npm packages in ES2015 code, it makes no difference whether that code the code one imports from is ES2015 or cross-compiled into CommonJS/ES5. So unless there is something specific in the ES2015 code that cannot be transpiled into ES5, I wonder what the advantages would be of offering a non-transpiled version like this. But maybe you know more about this?

[1] See for example https://github.com/ProseMirror
[2] See for example https://github.com/fiduswriter/biblatex-csl-converter

[johanneswilm]

This seems relevant:

Ideally, you should only be transforming your own source code, rather than running all of your external dependencies through Babel – hence the exclude: 'node_modules/**' in the example above. If you have a dependency that exposes untranspiled ES6 source code that doesn't run in your target environment, then you may need to break this rule, but it often causes problems with unusual .babelrc files or mismatched versions of Babel.

We encourage library authors not to distribute code that uses untranspiled ES6 features (other than modules) for this reason. Consumers of your library should not have to transpile your ES6 code, any more than they should have to transpile your CoffeeScript, ClojureScript or TypeScript.

https://github.com/rollup/rollup-plugin-babel#external-dependencies

[johanneswilm]

After some more googling, it seems like there used to exist a hackish solution for it for those importing the package that is now no longer working [1]. But it also seems everyone agrees that all code should be transpiled and not published only as ES6 code to npm.

cloverfield-tools/universal-react-boilerplate#41 (comment)

[johanneswilm]

Here is what I have added in the meantime so that I don't create dependency issues for others:

fiduswriter/biblatex-csl-converter@5287973

I would like to revert that.

[johanneswilm]

more issues with this: If I transpile edtf.js in my own library, then edtf.js turns into a dev-dependency for my library, as the compiled version is distributed in my package. When importing my lib into another project, however, the dependencies for nearley and randexp are missing.

[retorquere]

wouldn't a "prepublishonly" step fix all this?