Can't use Webpack 5?

MonteCarlo

I'm writing an extension for Flarum, and I've been following the docs for setting up webpack etc... The docs say to use Webpack 4, but I've seen on Github Flarum supports Webpack 5, and since 4 gives vulnerability warnings I figured I would use 5.

However, the issue that is stated to be fixed in this issue + PR here is still happening to me on v1.1.1
flarum/core2855
flarum/core3135

If I downgrade to 4, it works and does a console.log, otherwise if I upgrade to 5 it does the same error shown in the issue; index.js:94 Uncaught TypeError: {} is not a function

This is my package.json

{
    "private": true,
    "name": "my-ext",
    "dependencies": {
      "flarum-webpack-config": "^2.0.0",
      "webpack": "^5.0.0",
      "webpack-cli": "^4.0.0"
    },
    "devDependencies": {
      "flarum-tsconfig": "^1.0.0"
    },
    "scripts": {
      "dev": "webpack --mode development --watch",
      "build": "webpack --mode production"
    }
  }

rafaucau

MonteCarlo Support for Webpack 5 will be in the next version of Flarum (1.2)

MonteCarlo

rafaucau Oh, I saw it had been merged a while ago and figured it had already been released. Should I not be concerned about the vulnerability warnings being given by NPM for Webpack 4 then? Can't help but feel it's screaming red errors at me for an important reason 😅

clarkwinkelmann

I'm not aware of any Webpack 4 vulnerability that carries on to the compiled file.

Lots of the warnings or vulnerabilities are inside of libraries used by Webpack to compile the file, which might be dangerous to use in the context of a server-side Node.js application.

As long as you're compiling your own Flarum code, I don't think there's any way some external actor could attack your developer computer or Flarum itself.

The danger could be compiling unverified Flarum code from a public repository that's designed to exploit something in Webpack, but there are many ways for an extension to run arbitrary code on your development setup or Flarum without the need for a Webpack vulnerability so I don't see this as a preferred attack vector.