Skip to content

Using forge in a webpack packaging project #198

Description

@imrefazekas

Hello,

I tried to integrate forge into my project where webpack is used for module-based loading.
After trying to require the lib:

var forge = require('node-forge')({disableNativeCode: true});

I receive error while running:

ReferenceError: Left side of assignment is not a reference.

Has anyone success using forge with webpack in some way?

Activity

  1. dlongley commented on Dec 1, 2014

    @dlongley
    Member

    To help us investigate, could you provide a stack trace, line number, other debugging information? Is the above code the only code being run?

  2. harlantwood commented on Feb 16, 2015

    @harlantwood

    I had the same issue. To help reproduce it, I forked a simple webpack demo project, and added node-forge to it.

    Here is the stacktrace:

    Uncaught ReferenceError: Invalid left-hand side in assignment
    bundle.js:102 (anonymous function)
    bundle.js:144 forge.aes
    bundle.js:20 __webpack_require__
    bundle.js:47 name
    bundle.js:20 __webpack_require__
    bundle.js:40 (anonymous function)
    bundle.js:43 (anonymous function)
    

    And here is the bundle.js which is referred to: https://github.com/harlantwood/basic-webpack/blob/node-forge-webpack-issue/build/bundle.js#L102

    I'm not sure what's going on, but it would be great to be able to use forge with webpack... hope this helps.

    Note: if you want to rebuild the bundle locally after changes, you can say:

    node_modules/.bin/webpack
    
  3. dlongley commented on Feb 16, 2015

    @dlongley
    Member

    Ok, I see the issue is with the UMD boilerplate we're using. We temporarily redefine the global define function to allow the requireJS optimizer to parse and run properly -- and this is mucking up webpack's implementation. We'll have to figure out a fix for the boilerplate. Thanks @harlantwood.

  4. adamshone commented on Feb 18, 2015

    @adamshone

    As a stop-gap, I'm using Forge in a Webpack project by building it and referencing the bundle:

    • npm install node-forge
    • cd node_modules/node-forge
    • npm install
    • run node node_modules\requirejs\bin\r.js -o minify.js optimize=none out=js/forge.bundle.js. I borrowed this command from the last comment by @thorst on this issue: Issues bulding min file - opens r.js in visual studio #167
    • this spits out forge.bundle.js. Put this somewhere in your Webpack project
    • reference it the usual way: var forge = require('./forge.bundle');

    The downside is that you're pulling in the whole of forge (830KB) whereas if Webpack was minifying it would drop the bits of forge you are not using and you'd probably end up with something lighter. But it does work for now.

  5. nginnever commented on Feb 8, 2016

    @nginnever

    @dlongley Still having issues packaging node-forge. Have you been able to look into fixing the boilerplate you are using? I have been able to reproduce the "Error: No crypto" when trying to use @adamshone suggestion.

    Thanks!

  6. ysangkok commented on Feb 8, 2016

    @ysangkok

    @nginnever I just submitted a pull request that switches to CommonJS. It works with Webpack: #357

  7. UnsungHero97 commented on Feb 26, 2016

    @UnsungHero97

    thanks @adamshone! your forge.bundle.js solution seems to be working for me! one note, you can use an alias in webpack.config.js to make the require() statement a bit prettier:

    alias: {
      forge: 'path/to/forge.bundle.js'
    }
    

    With this alias, you can simply require forge:

    var forge = require('forge');
    
  8. Kadrian commented on Jul 5, 2016

    @Kadrian

    I've been trying all this, and now I'm getting a SyntaxError.

    Note that the alias should probably go under resolve. In my config, it looks like this:

    resolve: {
      root: path.resolve(__dirname),
      alias: {
        "node-forge": 'src/js/lib/forge.bundle.js'
      },
    },
    

    This uses the bundle when webpack serves / compile assets for the browser. My mocha tests still use node-forge directly as they run without webpack.

    But I still cannot get it to work. I've added:

    module: { 
      loaders: [ ... ], 
      noParse: [
        path.resolve(__dirname, './src/js/lib/forge.bundle.js')
      ]
    }
    

    Webpack still seems to parse it. At least when I require it like const forge = require('node-forge'); I'm getting the following error:

    ERROR in ./src/js/lib/forge.bundle.js
    Module build failed: SyntaxError: /Users/kai/app/src/js/lib/forge.bundle.js: Deleting local variable in strict mode (3410:4)
      3408 |   deps = (typeof ids === 'string') ? factory.slice(2) : ids.slice(2);
      3409 |   if(nodeJS) {
    > 3410 |     delete define;
           |     ^
      3411 |     return tmpDefine.apply(null, Array.prototype.slice.call(arguments, 0));
      3412 |   }
      3413 |   define = tmpDefine;
    

    The script I'm using to compile is postinstall.sh

    cd node_modules/node-forge
    npm install
    node node_modules/requirejs/bin/r.js -o minify.js optimize=none out=../../src/js/lib/forge.bundle.js
    

    which I'm including in my package.json as

    "scripts": {
      "postinstall" : "./scripts/postinstall.sh",
    }
    

    Anyone any idea how to resolve this?

  9. ysangkok commented on Jul 5, 2016

    @ysangkok

    @Kadrian try disabling strict mode? see #333

  10. Kadrian commented on Jul 5, 2016

    @Kadrian

    I'm not even running node with strict mode. My current suspicion is:

    • I'm using the babel-loader in webpack to compile ES6 code.
    • Although I've added the bundle to noParse, the file which does require('node-forge') is parsed by the babel-loader.
    • For babel compilation, I'm using the es2015 preset for ES6 support, which includes a couple of plugins, one of which seems to add "use strict" to all files (http://stackoverflow.com/questions/33821312/how-to-remove-global-use-strict-added-by-babel).
    • If "use strict" is added to the file that requires the forge bundle, the bundle gets parsed with "use strict" as well.

    Possible ideas for a workaround:

    • Create my own babel preset that leaves out the plugin that adds "use strict".
    • Copy the forge bundle over as an external and try to use it as a global object.
    • Go wild and try to find the non-strict occurrences in the bundle - fix them manually.

    My takeaways:
    => I do not understand noParse correctly yet - the webpack documentation is not very good there.

    UPDATE
    I fixed this situation by adding forge.bundle.js to my babel-loader exclude config:

    loaders: [{
      test: /\.js$/,
      exclude: /(node_modules|bower_components|forge\.bundle\.js)/,
      loader: 'babel-loader'
    }, { 
    ... 
    
  11. mjp0 commented on Aug 6, 2016

    @mjp0

    I'm running into this same issue but with Mocha tests. I'm using standard ES6 Mocha cmd mocha --compilers js:babel-register and at least I can't find any cli option to exclude anything from babel in this case.

    edit
    Nevermind, I got this working by using @Kadrian's resolve tip above. So you use import forge from 'node-forge' in your code and then put in webpack.config.js that it resolves node-forge package to forge-bundle.js that you've manually compiled. Now Mocha uses Node version and Webpack uses compiled version.

    edit2
    Actually doesn't still work as expected. Code coverage tool nyc/istanbul are still tripping over forge-bundle.js because you can't exclude files with Mocha which is used by nyc.

  12. hehoo commented on Aug 24, 2016

    @hehoo

    @dlongley have you figured out a fix for the UMD boilerplate. I also encountered the same problem when I used forge in webpack with strict mode. Why don't you try to pass the global object into the IIFE(Immediate Invocation Function Expression) for each JS file to fix the issue of "Uncaught ReferenceError: Invalid left-hand side in assignment"?

  13. dlongley commented on Aug 24, 2016

    @dlongley
    Member

    @hehoo,

    @davidlehn has a PR he's been working on to resolve the boilerplate and build system issues that he's nearly ready to submit for review. My understanding is that the PR switches everything over to CommonJS in the main files but includes options to build custom bundles with UMD boilerplate, etc. We'll likely auto-generate full bundles for releases. Anyway, that's forthcoming, we'll see here it goes.

  14. hehoo commented on Aug 25, 2016

    @hehoo

    @dlongley @davidlehn
    Thanks dlongley for your quick response. When the fix can be totally ready? Do you have the LE(latest estimation) for this:)? I'm trying to figure out whether your fix can catch my project's deadline.

  15. hehoo commented on Sep 20, 2016

    @hehoo

    @davidlehn and @dlongley Could you help to update me the progress of resolving the boilerplate and build system issues?

  16. added a commit that references this issue on Nov 16, 2016
  17. dlongley commented on Jan 11, 2017

    @dlongley
    Member

    Should be addressed in a new release now that #456 has been merged.

  18. added this to the v0.7.0 milestone on Jan 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions