gruntjs / grunt-contrib-jasmine

Run jasmine specs headlessly through Headless Chrome

Home Page:http://gruntjs.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

New tempDir logic seems to break grunt-contrib-jasmine-requirejs template. ReferenceError: Can't find variable: require

joutsen opened this issue · comments

The new logic of copyTempFile function is not backwards compatible with the logic expected by grunt-contrib-jasmine-requirejs.
"name": "grunt-template-jasmine-requirejs",
"version": "0.2.3"
In file template-jasmine-require.js line 63 task.copyTempFile(pathToRequireJS,'require.js'); copies the file to the root directory instead of temp dir. As the final error message I'm getting:

ReferenceError: Can't find variable: require at
_SpecRunner.html:34 global code

Just in case, my Gruntfile.js jasmine target:

jasmine:{
  "options": {
    "helpers": [
      "src/tests/**/*.helper.js",
      "_FiddleSpecSelector.js"
    ],
    "template": require('grunt-template-jasmine-requirejs'),
    "templateOptions": {
      "requireConfig": {
        "paths": {
          ...
        },
        "shim": {
          ...
        },
        "baseUrl": "src/assets/"
      }
    },
    "page": {
      "viewportSize": {
        "width": 2000,
        "height": 800
      }
    }
  },
  "unit": {
    "options": {
      "specs": "src/tests/unit/**/*.spec.js"
    }
  },
  "func": {
    "options": {
      "specs": "src/tests/func/**/*.spec.js"
    }
  },
  "all": {
    "options": {
      "specs": [
        "src/tests/unit/**/*.spec.js",
        "src/tests/func/**/*.spec.js"
      ]
    }
  }
}

Our team started seeing this issue as soon as the latest 1.1.0 release went out and we had to modify our project dependencies to exclude this version.

The same issue and solution in case of our project. However, shouldn't this issue be created in grunt-contrib-jasmine-requirejs @joutsen ?

I had an intention to report this to requirejs template project, but then decided to repot here, because I believe the upgrades of grunt-contrib-jasmine shouldn't just break the existing templates. I believe the contract with templates should be backwards compatible. Otherwise all projects depending on this combination just suddenly break. I hope this wasn't intended.

In my team we were having the exact same error and were only able to solve it by downgrading to 1.0.3

This new temp file logic puts temp files in the project root, whence the careless will commit them to version control and we'll have them forever. There's no way to tell a temp file apart from a real project file now. What was the thinking behind moving them out of .grunt/ ? That looks like a pretty good place for them to me.

Should be fixed

@vladikoff Is there any chance we this can be fixed off of 1.2.0 as well?

I am currently working on upgrading some of our dependencies at work, as we are currently on ^0.8.2 and tried to get us to 2.1.0, but having problems running chromium in a Docker container, so I bumped grunt-contrib-jasmine down to 1.2.0 and am now currently running into this.

In the meantime, I can go down to 1.0.3 it would seem, but trying to get this as up to latest as I can at this point.

@vladikoff, did you mean by closing this issue, that you won't fix the problem?

grunt-contrib-jasmine broke the interface of task.copyTempFile between 1.0.3 and 1.2.0 without increasing the major version number. (!!!) This change might affect plugins. And it did. It was reported by issue 93 of grunt-template-jasmine-requirejs.

The method task.copyTempFile does not copy the source file to the temp directory any more. You would have provide the full path to the temp directory yourself, when calling the method. It made this method a pure wrapper of grunt.file.copy with no added functionality and a confusing name.

This change appears to be an unintended side-effect of the introduction of the tempDir option by #240. How about this:

  1. Either fix the method to work with the temp directory again.
  2. Or remove the method task.copyTempFile altogether and recommend using just grunt.file.copy.

What do you think?

@prantlf we are at version 2+ now, I think we should probably fix the method to work with the temp dir again