externals in webpack.server.config.js causing error after deployment

[psenechal]

I'm submitting a...

[X] Bug report  
[ ] Feature request
[ ] Documentation issue or request

In package

[ ] @ng-toolkit/init
[X] @ng-toolkit/serverless
[ ] @ng-toolkit/universal
[ ] @ng-toolkit/pwa
[ ] @ng-toolkit/firebug

Current behavior

Creating a vanilla Angular 8 project, adding ng-toolkit/universal, ng-toolkit/serverless, ng-toolkit/pwa and deploying to AWS Lambda succeeds, but the application will not load.

Expected behavior

Application should load

Minimal reproduction of the problem with instructions

• Create a new Angular 8 project: ng new test
• Add universal: ng add @toolkit/universal
• Add serverless: ng add @toolkit/serverless
• Add pwa: ng add @angular/pwa; ng add @toolkit/universal
• Deploy to AWS: npm run build:serverless:deploy

Example repository

What is the motivation / use case for changing the behavior?

Not even sure it is @ng-toolkit that modifies webpack.server.config.js, but thought I would open an issue just in case. Please close if this has nothing to do with your library.

I tracked the issue down to the addition of the following to webpack.server.config.js:

externals: {
    './dist/server/main': 'require("./server/main")'
},

Commenting out this part allows the application to run successfully in Lambda.
I'm not sure if this is a new addition from webpack-cli, but I thought I would let you know that it is causing an issue after deploying to Lambda

Environment

Angular version: 8.2.13

- Node version: 12.6.0
- Platform:  Windows

Others:

[KingDarBoja]

@psenechal Umm, I will take a look at it, as far as I know, the deployment to AWS does work but we, as end users, must configure all the AWS related stuff to properly resolve route paths and all that stuff.

The good thing is that I have an already configured app with all the packages and deployed to aws, and I don't remember anything weird on the webpack.config.js file.

Can you share your file just for comparison purposes? 🍰

Cheers!

[psenechal]

You can see the lines I had to comment out in order to get it to load. Like I said, these might be something that webpack-cli is adding, but they were definitely the cause of the issue. Thanks for looking.

// Work around for https://github.com/angular/angular-cli/issues/7200

const path = require('path');
const webpack = require('webpack');

module.exports = {
  mode: 'none',
  entry: {
    // This is our Express server for Dynamic universal
    server: './server.ts',
    prerender: './prerender.ts'
  },
  /*externals: {
    './dist/server/main': 'require("./server/main")'
  },*/
  target: 'node',
  resolve: {
    extensions: ['.ts', '.js']
  },
  optimization: {
    minimize: false
  },
  output: {
    libraryTarget: 'commonjs2',
    // Puts the output at the root of the dist folder
    path: path.join(__dirname, 'dist'),
    filename: '[name].js'
  },
  module: {
    noParse: /polyfills-.*\.js/,
    rules: [{
        test: /\.ts$/,
        loader: 'ts-loader'
      },
      {
        // Mark files inside `@angular/core` as using SystemJS style dynamic imports.
        // Removing this will cause deprecation warnings to appear.
        test: /(\\|\/)@angular(\\|\/)core(\\|\/).+\.js$/,
        parser: {
          system: true
        },
      },
    ]
  },
  plugins: [
    new webpack.ContextReplacementPlugin(
      // fixes WARNING Critical dependency: the request of a dependency is an expression
      /(.+)?angular(\\|\/)core(.+)?/,
      path.join(__dirname, 'src'), // location of your src
      {} // a map of your routes
    ),
    new webpack.ContextReplacementPlugin(
      // fixes WARNING Critical dependency: the request of a dependency is an expression
      /(.+)?express(\\|\/)(.+)?/,
      path.join(__dirname, 'src'), {}
    )
  ]
};

[KingDarBoja]

@psenechal I am currently busy with job stuff but took time to look at my webpack.config.js file. For my surprise, I changed it to wepack.config.ts to enable typings but I wrote notes about it:

As you should know, the schematic @ng-toolkit/universal internally ran ng add @nguniversal/express-engine and hence generated a webpack server configuration file webpack.server.config.js. This file got changed to Typescript language to support ES Module Import but the drawback was NodeJS not being able to recognize such imports.

To fix this, follow the Configuration Languages documentation at webpack site.

This is my current config file as seen here. Please notice I don't have any externals option there.

And this was generated with version 8.0.0 while on development.

Cheers!

[psenechal]

Correct...I had generated a project a few months ago using Universal and that one also didn’t have the “externals” option. The one that did was only generated this last week, so my assumption is that webpack-cli must have generated the file with that option.

Good to know...perhaps we can close this, but leave it in case anyone else runs across this issue?

In the meantime, I’ll try to figure out why that “externals” option causes a problem on Lambda and post in the webpack-cli project.

Thanks for taking the time to look...appreciate it.

[KingDarBoja]

@psenechal Let me test again with a new project just to see if the externals option shows up.

I will be back and edit this comment with my findings.

UPDATE
After running a new project then ng add @ng-toolkit/universal, the webpack.config.js file is being generated as expected BUT there is the same externals key being included and there isn't anything on this library including this line.

So as you guessed, it is related to webpack, by checking the official documentation here, which states:

The externals configuration option provides a way of excluding dependencies from the output bundles. Instead, the created bundle relies on that dependency to be present in the consumer's environment.

I will dig into this, so keeping the issue open to document my findings.

[KingDarBoja]

@psenechal Well, I found the issue after all, looks like that webpack.config.js file is being generated by the ng add @nguniversal/express-engine (internally used by @ng-toolkit/universal) and that external option is being added but not working atm.

Related issue at Angular Universal repo.

Extra migration guide (should check it first to test if missing anything).