failure "empty command evaluates to undefined" with nodejs 4.8.2

[jonassmedegaard]

Hi,

Coffeescript 1.12.5 fails when built with Nodejs 4.8.2 (the version in Debian unstable/testing).
with the following error message and stacktrace:

bin/cake build:full
failed 1 and passed 834 tests in 23.65 seconds 

  empty command evaluates to undefined 
  AssertionError: Expected undefined to equal coffee> 
    at exports.eq (/build/coffeescript-1.12.5~dfsg/test/support/helpers.coffee:16:34)
    at /build/coffeescript-1.12.5~dfsg/test/repl.coffee:1:1
    at Function. (/build/coffeescript-1.12.5~dfsg/test/repl.coffee:1:1)
    at global.test (/build/coffeescript-1.12.5~dfsg/Cakefile:1:1)
    at testRepl (/build/coffeescript-1.12.5~dfsg/test/repl.coffee:1:1)
    at Object. (/build/coffeescript-1.12.5~dfsg/test/repl.coffee:1:1)
    at Object. (/build/coffeescript-1.12.5~dfsg/test/repl.coffee:1:1)
    at Module._compile (module.js:1:1)
    at Object.exports.run (/build/coffeescript-1.12.5~dfsg/lib/coffee-script/coffee-script.js:1:1)
    at runTests (/build/coffeescript-1.12.5~dfsg/Cakefile:1:1)
    at testBuiltCode (/build/coffeescript-1.12.5~dfsg/Cakefile:1:1)
    at /build/coffeescript-1.12.5~dfsg/Cakefile:1:1
    at ChildProcess. (/build/coffeescript-1.12.5~dfsg/Cakefile:1:1)
    at emitTwo (events.js:1:1)
    at ChildProcess.emit (events.js:1:1)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:1:1)
 
  function () {
      return fn(input, output, repl);
    }

If instead using Nodejs 6.10.2 (in Debian experimental) the testsuite succeeds.

[GeoffreyBooth]

The module includes built files, in the lib folder. There’s no need to build CoffeeScript yourself to run the compiler. Just run bin/coffee.

For development purposes it is assumed that you’re running the latest version of Node. We’re not supporting development cake commands in older runtimes.

[jonassmedegaard]

Quoting Geoffrey Booth (2017-04-15 20:58:13)

The module includes built files, in the `lib` folder. There’s no need to build CoffeeScript yourself to run the compiler. Just run `bin/coffee`. For development purposes it is assumed that you’re running the latest version of Node. We’re not supporting development `cake` commands in older runtimes.

Reason I cared to report this issue was that it seems from looking at package.json that the project claims to support Node as old as 0.8.0. Which versions of node do Coffeescript support? - Jonas

…

-- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private

[GeoffreyBooth]

The compiler runs in Node > 0.8.0. As in, using the built code (e.g. bin/coffee) should work in old versions of Node. If that isn’t the case, please open an issue.

Running the cake commands (building a new compiler, running the tests etc.) assume current Node.

[jonassmedegaard]

Quoting Geoffrey Booth (2017-04-15 22:33:25)

The compiler _runs_ in Node > 0.8.0. As in, using the built code (e.g. `bin/coffee`) should work in old versions of Node. If that isn’t the case, please open an issue. Running the `cake` commands (building a new compiler, running the tests etc.) assume current Node.

So building this project from source is not generally supported - only when done on newest Nodejs. This is very surprising for me, but I will respect your decision. Most likely the consequence will be that Coffeescript have to be removed from Debian, along with any and all projects depending on Coffeescript. Quite sad. - Jonas

…

-- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private

[GeoffreyBooth]

Let me be more specific. The newest versions of CoffeeScript support things like generator functions that are not supported in old versions of Node. To test that support, the tests run generators via the runtime, and therefore the tests require a runtime that supports generators. So yes, running the tests requires a current version of Node.

Simply building or running the compiler, however, does not. If you type simply cake you’ll see that cake build:full builds the compiler and then runs the tests. But just running cake build, to build the compiler and stop, does work in Node 4.6.2.

Furthermore the JavaScript output that is generated by cake build is checked into the repo. It’s in the lib folder. This is what we expect downstream tools to use, and this is what bin/coffee and both top-level .js files point to. There’s additionally a merged version of the JavaScript sources in docs/v1/browser-compiler/coffee-script.js. I would consider all of them to be the CoffeeScript “source,” as they’re all in the repo.

The browser compiler, in particular, doesn’t even depend on Node; it runs in browsers, and the v1 browser compiler should run in very old versions of Node. Generally downstream tools that import CoffeeScript, like the Ruby coffee-script gem, use the browser compiler for maximum compatibility.

[jonassmedegaard]

Quoting Geoffrey Booth (2017-04-15 23:14:51)

Let me be more specific. The newest versions of CoffeeScript support things like generator functions that are not supported in old versions of Node. To test that support, the tests run generators via the runtime, and therefore the tests require a runtime that supports generators. So yes, running the tests requires a current version of Node. Simply building or running the compiler, however, does not. If you type simply `cake` you’ll see that `cake build:full` builds the compiler and then runs the tests. But just running `cake build`, to build the compiler and stop, _does_ work in Node 4.6.2. Furthermore the JavaScript output that is generated by `cake build` _is checked into the repo._ It’s in the `lib` folder. This is what we expect downstream tools to use, and this is what `bin/coffee` and both top-level `.js` files point to. There’s additionally a merged version of the JavaScript sources in `docs/v1/browser-compiler/coffee-script.js`. I would consider all of them to be the CoffeeScript “source,” as they’re all in the repo. The browser compiler, in particular, doesn’t even depend on Node; it runs in browsers, and the v1 browser compiler should run in very old versions of Node. Generally downstream tools that import CoffeeScript, like the [Ruby `coffee-script` gem](https://github.com/rails/ruby-coffee-script/blob/63622bfd87a9d06c50f87ef887a5f9e3b80b4cdd/script/build-source-gem#L23), [use the browser compiler](https://github.com/rails/ruby-coffee-script/blob/63622bfd87a9d06c50f87ef887a5f9e3b80b4cdd/script/build-source-gem#L23) for maximum compatibility.

Thanks for the clarification. I think I understand better now. Let me try rephrase to see if I understand correctly: It is not an arbitrary limitation that "only latest Nodejs is supported" but instead that recent build process and corresponding tests require features only available in recent Nodejs. Did I get that correctly? Makes good sense. And also admirable that you _additionally_ support use of the prebuilt code even for older versions of Nodejs. The situation at my end - the Debian distribution - is however that we require all code to be built from source, and we maintain that code as "stable" (i.e. without any feature changes, only security fixes) for several years. We therefore cannot¹ distribute prebuilt code, but if I understand you correctly ypur recent code is expected to be buildable by _currently_ recent tools for as long as those tools are available - which is potentially longer in Debian than common outside of Debian, due to our conservative policies. Regards, - Jonas ¹ I am speaking about the official Debian distribution above. We also maintain packages not part of the "main" distribution, but such "contrib" and "non-free" parts are discouraged and thus receive far less attention and care.

…

-- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private

[GeoffreyBooth]

recent build process and corresponding tests require features only available in recent Nodejs.

No. The build process does not require recent Node. The build process works in Node 4.6.2, if not earlier. That’s what happens when you run the command cake build. (Type just cake to see explanations of all the commands.)

The tests fail in Node 4.6.2, presumably because they’re expecting the runtime to support features that Node 4.6.2 doesn’t have. We could, I suppose, add some checks to filter out the tests that don’t make sense to run under Node 4. Or you could, since you’re patching CoffeeScript anyway 😉

But I guess it depends what you mean by “build.” Does build simply mean compiling the CoffeeScript into JavaScript, or does it mean doing that and running the tests (and having them all pass)? If the former, then you’re done; the code already builds in Node 4. If the latter, I suggest you create another patch that comments out or deletes any offending tests.

I also wonder what “require all code to be built from source” means for a language like JavaScript. It’s not like cake build produces a platform-dependent binary, like compiling C code. The JavaScript produced by cake build is both a generated output, yes, but they’re also very much source files: the code in lib is human-readable. Lots of projects have only .js files as their source. Considering that the CoffeeScript project’s JavaScript files are source files, platform-independent, human-readable and checked into the repo, why wouldn’t you consider these files the “source” for the purposes of your policy?

The engines: node key in package.json refers to the Node runtime required to run the JavaScript files by another Node project that is including this module, or when running the coffee binary at the command line. It just isn’t meant to refer to the minimum Node runtime required for building the code or running the tests. If you do npm install coffee-script and look inside the resulting node_modules/coffee-script folder, you’ll notice that there are only JavaScript files in there. That’s all we distribute, and that’s all that gets hosted on NPM or used by other Node modules.

[jonassmedegaard]

Quoting Geoffrey Booth (2017-04-16 09:01:33)

> recent build process and corresponding tests require features only > available in recent Nodejs. No. The build process does not require recent Node. The build process works in Node 4.6.2, if not earlier. That’s what happens when you run the command `cake build`. (Type just `cake` to see explanations of all the commands.) The _tests_ fail in Node 4.6.2, presumably because they’re expecting the runtime to support features that Node 4.6.2 doesn’t have.

Ah, even better :-) Then we can backport our coffeescript package to Debian releases using older Nodejs, if we a) skip (problematic parts of) build-time testsuite and instead b) manually copy the built code to a newer environment and run the tests there. That is (cumbersome but) doable for us.

We could, I suppose, add some checks to filter out the tests that don’t make sense to run under Node 4. Or you could, since you’re patching CoffeeScript anyway 😉

I certainly don't want to impose burden on you for stuff you do not wish to support. That said, since you seem to know exactly the things known to fail on older Nodejs (as opposed to tests expected to always succeed) I would sure appreciate if you would add a flag to skip known-modern tests. Perhaps label such flags by the baseline version of nodejs which should support it - e.g. like this: build:full → whatever most modern build:node5 → should succeed with Nodejs 5.0.0 or newer build:node0.8.0 → should succeed with Nodejs 0.8.0 or newer Alternatively, if you see too little benefit for you in doing that work, I would appreciate any and all details on what I should myself narrow down and comment out for the current issue I have. I can then chime in concretely next time I might hit a similar issue (if ever...).

But I guess it depends what you mean by “build.” Does build simply mean compiling the CoffeeScript into JavaScript, or does it mean doing that _and_ running the tests (and having them all pass)? If the former, then you’re done; the code already builds in Node 4. If the latter, I suggest you create another patch that comments out or deletes any offending tests.

I distinguish between "build" and "test". With "build" I mean whatever involved to get from your preferred form of source to the code used in production. Concatenation and minification both derive the code away from its upstream preferred form of source. For coffeescript I consider the "build" process to include transforming any and all coffeescript code to javascript code - including the jison lexer, and including the code to run cake itself. (I am aware that coffeescript bootstraps itself from previously built code. Ideally bootstrapping was self-contained - e.g. a separate bootstrapping-only-cake maintained as hand-written javascript, instead of simply building twice - but I am currently ignoring that).

I also wonder what “require all code to be built from source” means for a language like JavaScript. It’s not like `cake build` produces a platform-dependent binary, like compiling C code. The JavaScript produced by `cake build` is both a generated output, yes, but they’re also very much source files: the code in `lib` is human-readable. Lots of projects have only `.js` files as their source. Considering that the CoffeeScript project’s JavaScript files _are_ source files, platform-independent, human-readable and checked into the repo, why wouldn’t you consider these files the “source” for the purposes of your policy?

You are not the only one wondering - not by far :-) The issue is not if code is readable in a plaintext editor. Nor is the issue if code is suitable as basis for derived works. Issue is if the code is _your_ preferred form for editing. Our aim is not only to distribute for production. Debian considers itself to be the universal operating system, and believe that involves two-way communication: Not only downwards for consumption, but also upstream towards projects like yours. Imagine a Debian user creating a derivative work from Coffeescript, and then spots a bug in their code, then they should be able to track back and identify the same code fragment in your upstream development source, to be able to provide you a pull request. If we provided our users with code possible for them to edit but a different form than the code you yourself edit, then we limit the ability for our users to pass back changes to you. Another example is our own security team: If they spot a security issue 3 years from now, in code you no longer care about, then you might still care about whether or not that issue still exist but maybe in a slightly different form somewhere in your current code. I am not the best person to "sell" this. If you are still not convinced there is any sense to Debian logic on this (whether or not you _agree_ to that logic) then tell me and I shall try find arguments of others far better than me in explaining it.

The [`engines: node` key](https://docs.npmjs.com/files/package.json#engines) in `package.json` refers to the Node runtime required to run the JavaScript files by another Node project that is including this module, or when running the `coffee` binary at the command line. It just isn’t meant to refer to the minimum Node runtime required for building the code or running the tests. If you do `npm install coffee-script` and look inside the resulting `node_modules/coffee-script` folder, you’ll notice that there are only JavaScript files in there. That’s all we distribute, and that’s all that gets hosted on NPM or used by other Node modules.

Thanks. Makes sense: That hint is for runtime use by npm, not for build-time use. Debian packaging _replace_ the use of npm. Perfectly understandable if you find npm fine and you encourage all users to rely on npm, but that tool does not fit the needs of Debian. I appreciate your patience in spelling it out to me. - Jonas

…

-- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private