module.exports drama and how to access webpack-chain config.output in quasar.conf.js?



  • Hi! Trying to get moved over to using quasar-cli with an existing project and running into some difficulties. Specifically, the project uses module.exports for some files shared by a node.js backend and a quasar frontend. But this makes webpack not happy:

    Uncaught TypeError: Cannot assign to read only property ‘exports’ of object ‘#<Object>’

    I understand that you can’t import a file that uses module.exports, you have to require it instead. But I am requiring it and am still getting this error.

    If only I could switch everything to import/export! But then node.js isn’t happy. Support of import/export on node is extremely experimental, only on the bleeding edge of node.js, and requires a .mjs extension. Or at least that’s as far as I read before I thought… there must be a better way!

    So, I’ve been flailing around for a while trying to figure out how to make this work. It was working with my old setup (had installed quasar-framework as a vue cli 3 plugin) that used webpack 3.7.1. I’ve tried a few different versions of webpack 4.x (saw a bug in a recent release that I thought might be related to the issue), but none are working. Avoiding switching back to 3.7.1 because I’m worried it might break lots of things that quasar-cli might need. I’m currently on webpack 4.16.1

    While in my crazed search for anything that might help, I saw a suggestion to try setting webpack’s output.libraryExport setting to default. So I wanted to try it. But I can’t. I’m trying to do this within quasar.conf.js’s build.extendWebpack with the following line:

    cfg.output.libraryExport(‘default’)

    Which as far as I can tell should be valid from the webpack-chain API, but cfg.output is null. Is cfg.output restricted for some reason? Am I too far down the chain to access it or something? I don’t know. I’m used to the standard webpack conf files, webpack-chain is magic as far as I know. I don’t have much hope that this will work anyway, but I would love to try it.

    Please save me from having to copy a bunch of common files into a new location to change just one line, and from then on forevermore have to maintain both copies. It makes my DRY programmer heart want to gag.

    Thank you for reading. This has been a little cathartic.

    -Jenny



  • Aha! It’s working! Just had to add commonjs as a module to my .babelrc!

    Still curious why cfg.output isn’t available in extendWebpack, but obviously it’s not so urgent feeling now.

    Now I can go to bed. 🙂



  • Glad it worked for you. One thing you should keep in mind though, is that as Babel moves away from their presets you will have much more granular control over the plugins and modules. I sense we are going to be seeing more issues like yours in the near future.



  • On a sidenote, please feel free to visit our discord server. We are great at rubber duck debugging. 🙂



  • Thanks for the tip! And I’ll make sure to check out the discord server, I’ve been meaning to anyway.



  • @nejlyn great that you fixed it I am having the same issue! Any chance of a bit more detail on how you added commonjs as a module to your .babelrc or could you post yours? Cheers!



  • @metareason Sure thing, hope it helps you!

    {
    “presets”: [
    [
    "@babel/preset-env", {
    “modules”: “commonjs”,
    “loose”: false,
    “useBuiltIns”: “usage”
    }
    ],
    [
    "@babel/preset-stage-2", {
    “modules”: “commonjs”,
    “loose”: false,
    “useBuiltIns”: true,
    “decoratorsLegacy”: true
    }
    ]
    ],
    “plugins”: [
    [
    "@babel/transform-runtime", {
    “polyfill”: false,
    “regenerator”: false
    }
    ]
    ],
    “comments”: false
    }