What are the semantics of the src-property?

[hessellund]

When I run with a configuration like this:

  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    manifest: grunt.file.readJSON('manifest.json'),
    crx: {
      staging: {
        "src": [
          "bower_components/font-awesome/fonts/**",
          "bower_components/font-awesome/css/font-awesome.min.css",
          "bower_components/jquery/dist/jquery.min.js",
          "bower_components/lodash/dist/lodash.min.js",
          "icons/**",
          "src/**",
          "manifest.json",
          "!*.pem"
        ],
        "dest": "dist/staging/src/<%= pkg.name %>-<%= manifest.version %>-dev.crx",
        "options": {
          "baseURL": "http://my.app.intranet/files/",
          "filename": "",
          "privateKey": "cert.pem",
          "maxBuffer": 3000 * 1024 //build extension with a weight up to 3MB
        }
      },

I get the following error?

Running "crx:staging" (crx) task
Warning: Unable to read "bower_components\font-awesome\fonts\manifest.json" file (Error code: ENOENT). Use --force to continue.

Aborted due to warnings.

Is this a bug?

[thom4parisot]

Which version of grunt-crx do you run?

[hessellund]

I am using version 0.3.4. I tried copying all my source file tree into a tmp folder and then use that as my src-property. That seems to work...

Except I get to the following step and then nothing happens:

Running "crx" task

Running "crx:staging" (crx) task
Verifying property crx.staging exists in config...OK
Files: tmp -> dist/deltek-tfs-p4-0.0.1-beta.crx
Reading d:\Projects\personal-tfs-p4\node_modules\grunt-crx\lib/../data/config-default.json...OK
Parsing d:\Projects\personal-tfs-p4\node_modules\grunt-crx\lib/../data/config-default.json...OK
Reading key.pem...OK
Reading tmp\manifest.json...OK
Parsing tmp\manifest.json...OK
Reading package.json...OK
Parsing package.json...OK

I should probably say that I am trying to run this on a Windows 7 box with cygwin installed. Some (actually a lot) of NodeJS libs don't work very well on Windows.

[thom4parisot]

Sorry about that, have a look at 0.3.4 README instead: https://github.com/oncletom/grunt-crx/blob/v0.3.4/README.md

The displayed one is related to the 1.0.0 branch – which is not yet secure enough for production.

[hessellund]

Ok, thanks. Same error, now with this configuration

    crx: {
      staging: {
        "src": "tmp/",
        "dest": "dist/<%= pkg.name %>-<%= manifest.version %>-beta.crx",
        "baseURL": "http://my.app.intranet/files/",
        "filename": "",
        "exclude": "*.pem",
        "privateKey": "key.pem",
        "options": {
          "maxBuffer": 3000 * 1024 //build extension with a weight up to 3MB
        }
      }

I dug a little deeper. It seems that during the execution of the crx.staging task, a tmp folder is created. Inside that my bower-folder is copied and then a crx-blah blah folder is created. Inside the crx-folder this structure is repeated and so on - turtles all the way down. This is why the task doesn't terminate.

I haven't found the source of this error in the code.

[thom4parisot]

Do you have a cycling dependency or a symlink somewhere in that loop?

[hessellund]

No cyclic dependencies that I am aware of :)

And no symlinks on WIndows...

Could you perhaps direct me to the part of your code that creates these folders? Perhaps I can figure it out with a little trial and error.

Thanks.

[poxip]

On Linux (Ubuntu x86-64) README.md for version 0.34 works well.

[thom4parisot]

@hessellund have you tried packaging the extension with crx directly? At least we will know if it is related to the core module itself or to its grunt plugin.

[hessellund]

Hi, sorry for the delayed response. I just tried running a test of just crx. That also fails.

My extension is placed in a folder called personal-tfs-p4. It works perfectly when I load it as an unpackaged extension in Chrome. However, when I run the following pack command with crx, it fails. Any ideas?

 D:\Projects>crx pack personal-tfs-p4 -o extension.crx
 Key file has been generated at D:\Projects\personal-tfs-p4\key.pem

 events.js:72
         throw er; // Unhandled 'error' event
               ^
 Error: EMFILE, open 'C:\Users\ANDERS~1\AppData\Local\Temp\crx115124-8520- aw5d4n\node_modules\bower\node_modules\tar-fs\node_modules\tar-stream\.npmignore'

 D:\Projects>

I also tried running the exact same command on a linux box and that works perfectly. So it seems to be a WIndows-issue. Unless someone knows how to fix this, I think you should at least put a disclaimer in the docs stating that Windows (even with cygwin) is not supported.

Cheers,

Anders

[thom4parisot]

Hard to say, I don't have access to a Windows machine and I think all modules are now pure JS so there should be any platform related issues. EMFILE is related to 'too many files opened'. Maybe your extension is large and/or the way the extension collects the file is less performant than before.

Do you have an idea of how many files are contained in your extension? Also the filepath is weird, cf node_modules\bower\node_modules\tar-fs\node_modules\tar-stream.

Did you have time to investigate the problem a bit further?

[hessellund]

No, I used crx directly and got it to work on a linux VM. Never cracked the Windows problem. Had to move on.

Thanks for you help,

Anders

On Tue, Jun 16, 2015 at 11:00 AM, Thomas Parisot notifications@github.com wrote:

Hard to say, I don't have access to a Windows machine and I think all modules are now pure JS so there should be any platform related issues. EMFILE is related to 'too many files opened'. Maybe your extension is large and/or the way the extension collects the file is less performant than before.

Do you have an idea of how many files are contained in your extension? Also the filepath is weird, cf node_modules\bower\node_modules\tar-fs\node_modules\tar-stream.

Did you have time to investigate the problem a bit further?

— Reply to this email directly or view it on GitHub https://github.com/oncletom/grunt-crx/issues/48#issuecomment-112346795.

[thom4parisot]

:+1: