Problem with the hot-reload in Atlassian WRM webpack plugin (for Data Center)

Hi,

Has anyone succeeded to run https://bitbucket.org/serverecosystem/wrm-webpack-example and get the hot reload working in 2022?

I did! It’s awesome, I modify JS files and, if webpack-watch is running in the background, Confluence reloads the module without refreshing the page! It’s stunning!

But I don’t succeed to upgrade it to the most recent version of Atlassian WRM webpack plugin, and to Webpack 5. Can anyone help? In exchange, I’ve successfully upgraded it to a recent version of AMPS and Confluence, and I’ve made it into a nice PR to compare before the upgrade/after the upgrade:

https://bitbucket.org/requirementyogi/wrm-webpack-example/pull-requests/1/upgrading-to-webpack-5-and-atlassian-wrm

In particular, I wonder whether I have configured the dev-server properly, and if the chunkIds: "named" parameters have the correct effect:


    devServer: {
        host: hostname,
        port: devServerPort,
        client: {
            overlay: true,
            progress: true
        },
        hot: true,
        headers: {
            'Access-Control-Allow-Origin': '*',
            'Access-Control-Allow-Headers': 'x-atlassian-mau-ignore'
        },
        allowedHosts: [
            '.local' // (for upgrade to Webpack 5)
        ]
    },

It’s all in the PR, if you can help me. Thank you heaps, and I’ll put the results back here, probably (hopefully with a demo project, so everyone will be able to use webpack’s hot reload on Jira DC). https://bitbucket.org/requirementyogi/wrm-webpack-example/pull-requests/1/upgrading-to-webpack-5-and-atlassian-wrm

Alternatively, please give me your webpack.config.js if you support the hot-reload in your Confluence/Jira pages, and the associated package.json. But I suppose those are hard-earned fruits of each one’s labour…

5 Likes

Hi @aragot, I’m not sure what issue or error you have currently, but you might want to check those configs to find some inspiration about hot-reload:

Thanks,
Maciej

Hi Maciej,

Thank you very much for answering;

Nowadays we’re using Webpack 5 / WRM 5.2.9, and those examples are still using Webpack 4.41.5 (and associated libraries) and atlassian-webresource-webpack-plugin 5.0.1, and I think it’s the upgrade that breaks something. Perhaps an option is required.

Would you have an example with Webpack 5?

Thank you very much for sharing the files in any case - very helpful.

Best regards,
Adrien Ragot

@aragot, did you fix the problem with hot reload?

We’ve found similar problem with webpack 5.74.0 and webpack-dev-server 4.10.1.

In the log below the ‘pos’ is name of our entrypoint and 192.168.6.117 IP address of dev computer.

[HMR] Update failed: Loading hot update chunk pos failed.
(undefined: undefined)
loadUpdateChunk/<@http://192.168.6.117:3333/runtime.js:654:26
loadUpdateChunk@http://192.168.6.117:3333/runtime.js:649:20
__webpack_require__.hmrC.jsonp/<@http://192.168.6.117:3333/runtime.js:1109:29
__webpack_require__.hmrC.jsonp@http://192.168.6.117:3333/runtime.js:1104:22
hotCheck/</</<@http://192.168.6.117:3333/runtime.js:495:47
hotCheck/</<@http://192.168.6.117:3333/runtime.js:491:55
promise callback*hotCheck/<@http://192.168.6.117:3333/runtime.js:486:43
promise callback*hotCheck@http://192.168.6.117:3333/runtime.js:477:15
check@http://192.168.6.117:3333/pos.js:44290:5
./node_modules/webpack/hot/dev-server.js/<@http://192.168.6.117:3333/pos.js:44331:4
emit@http://192.168.6.117:3333/pos.js:13305:17
reloadApp@http://192.168.6.117:3333/pos.js:44176:67
ok@http://192.168.6.117:3333/pos.js:42555:68
initSocket/<@http://192.168.6.117:3333/pos.js:43803:29
onMessage/this.client.onmessage@http://192.168.6.117:3333/pos.js:42316:10
EventHandlerNonNull*onMessage@http://192.168.6.117:3333/pos.js:42315:7
initSocket@http://192.168.6.117:3333/pos.js:43795:10
./node_modules/webpack-dev-server/client/index.js?protocol=ws%3A&hostname=192.168.6.117&port=3333&pathname=%2Fws&logging=info&overlay=true&reconnect=10&hot=true&live-reload=true@http://192.168.6.117:3333/pos.js:42655:55
__webpack_require__@http://192.168.6.117:3333/runtime.js:28:33
__webpack_exec__@http://192.168.6.117:3333/pos.js:44817:67
@http://192.168.6.117:3333/pos.js:44818:53
webpackJsonpCallback@http://192.168.6.117:3333/runtime.js:1152:46
@http://192.168.6.117:3333/pos.js:1:67

Hi Kbujacek,

No I haven’t found the issue. Confluence sends mysterious packets through a ws:// socket, they’re unreadable, and, for the previous version it triggers a reload, and for the next version it doesn’t trigger anything, there’s no explanation anywhere.

Atlassian WRM doesn’t work with Webpack 5.x, as far as I’m concerned.

I wonder what Atlassian uses internally. And what are all the teams working on, if they’re not working on the hundreds of internal plugins that (must) be using Webpack.

Best regards.

2 Likes

Has anyone found the solution to this issue? It’s very annoying to be forced to stick with webpack 4 because of this.

Also, if someone is using React I found that there is a issue too with lazy loading components if you don’t modify the splitChunk optimizations in webpack 4. In webpack 5 everything works as expected.

I have webpack 5 but not the hot reload, and the “quick reload” (reading the compiled TS resources when reloading the page) works really bad in Confluence 8.0+, like 30 times and then Confluence basically crashes. Are you still interested in my setup?

Thanks @aragot but I have already that setted up too (compiling TS and all resources fine with “quick reload”), but when you work with React, having to reload the page very much slows the dev experience.

I really appreciate your answer, but until I can have hmr in webpack 5 migrating is a leap backwards.

This is my devServer config for webpack5

devServer: {
      hot: true,
      compress: true,
      host: host,
      port: port,
      allowedHosts: "all",
      https: {
        key: fs.readFileSync("./../certs/dev.local.key"),
        cert: fs.readFileSync("./../certs/dev.local.crt"),
      },

      headers: {
        "Access-Control-Allow-Origin": "*",
        "Access-Control-Allow-Methods":
          "GET, POST, PUT, DELETE, PATCH, OPTIONS",
        "Access-Control-Allow-Headers":
          "X-Requested-With, content-type, Authorization",
      },
    },
    ignoreWarnings: [/only default export is available soon/],

I use GitHub - pmmmwh/react-refresh-webpack-plugin: A Webpack plugin to enable "Fast Refresh" (also previously known as Hot Reloading) for React components. in combination with SWC instead of babel.

{
          test: /\.(js|jsx|tsx|ts)$/,
          exclude: /node_modules/,
          use: [
            {
              loader: "swc-loader",
              options: {
                jsc: {
                  transform: {
                    react: {
                      development: argv.mode === "development",
                      refresh: argv.mode === "development",
                    },
                  },
                },
              },
            },
          ],
        },
stefanernst@dev ~/r/s/js (main)> cat .swcrc
[{
     "test": ".tsx?$",
     "jsc": {
       "parser": {
         "syntax": "typescript",
         "tsx": true,
         "decorators": false,
         "dynamicImport": true
       },
       "transform": {
         "react": {
           "refresh": true
         }
       }
     }
   },
{
    "test": ".jsx?$",
    "jsc": {
      "parser": {
        "syntax": "ecmascript",
        "jsx": true,
        "decorators": false,
        "dynamicImport": true
      },
      "transform": {
        "react": {
          "refresh": true
        }
      }
    }
  }
]

I do not use code splitting, I just manually control my entrypoints and the resulting js files. This gives you also the opportunity to move away from the WRM plugin. You can simply copy the wr-defs.xml output to your atlassian-plugin.xml and be done with it. If you want to move to vite in the future, its easier. The less moving parts, the better.

2 Likes

Thank you very much @ernst.stefan ! I also use that plugin but with babel instead of SWC in webpack 4.

I’ll give it a try and get back to you with the result.

Just one more question, how are you doing the code splitting? In my case I personally do the same as you but in this case i’m forced by an Atlaskit dependency that lazy loads the component.

P.S.: I’d love to use vite, but if I have to rely on Atlassian making a plugin for it, I can sit and wait.

I have to admit, I also moved away from Atlaskit because of its many problems. So I just use the styling but not the components :frowning:
It improves bundle size however, so I don’t have to code split :slight_smile:

Great move, if I had the time I would do it too for sure.

1 Like