Why are global vars undefined when using module.exports? RESOLVED

Why are global vars undefined when using module.exports? RESOLVED
0
#1

Anyone familiar with modules, as in using module.exports and requiring that file in another?

I’ve implemented it, (Webpack is combining the two files into a bundle.js) but now my previously working functions are complaining that variables are not defined. In particular a global variable defined in my main app.js file (kinda stores the app state so is needed to be accessible throughout the app), but needed in a function I moved to the helpers.js module. I’m wondering if I need to move this global variable to the module… but then it won’t be available to the main app.js file. I’ve tried various things such as prefixing with ‘window.’ , using ‘export let myGlobalVar’ in the module file but am not getting very far.

All the resources I’ve found show how to get a module to import, but none seem to discuss use of global vars (yes, I know generally not to use them, but this one is storing the state that is used everywhere), or general guidance on how to troubleshoot/restructure/rewrite code once you’ve moved it to a module, for it to continue to function correctly.

Update: This is not an Express app. It’s just a basic front-end app. All I want to do is split out some functions into their own file and use webpack to recombine them back into a single file. I believe you can do a similar thing with multiple script tags in the index.html file to include multiple js files, but I’m trying to do it in a more scalable way with Webpack.

Any advice/guidance appreciated, I think I have a fundamental piece of understanding missing.

Cheers,
Tim.

#2

I think you want to pass variables around using middleware rather than global variables.

Middleware acts as a way to inject particular objects (variables / database connections etc) into all Express requests.

I’m not 100% certain of this, and I’m not sure what it would look like in your specific case, but I think you wanna read up on middleware practices in Express and see if it rings any bells.

#3

Hi Jackson, thanks for replying. This is not an Express app. It’s just a basic front-end app. All I want to do is split out some functions into their own file and use webpack to recombine them back into a single file. I believe you can do a similar thing with multiple script tags in the index.html file to include multiple js files, but I’m trying to do it in a more scalable way.

#4

Oh, I see. My bad.

I have no idea then :slight_smile:

#5

You are saying prefixing with window. didn’t help. Are you sure something like:

//globals.js
window.GLOBALS  = {...};

------------------------------------

//somewhere_else.js
import 'globals';
//or
require('globals');

doesn’t work?

My preferred way is:

//globals.js
const GLOBALS = {...};

export default GLOBALS;
//or
module.exports = GLOBALS;

------------------------------
//somewhere_else.js
import GLOBALS from 'globals';
//or
const GLOBALS = require('globals');

There is also an option to define global constants to be inlined at compile time with DefinePlugin:

plugins: [
  new webpack.DefinePlugin({
    PRODUCTION: JSON.stringify(true),
  });
]

will replace every instance of PRODUCTION variable in your code with “true”. This is especially useful when you want to execute different parts of your code based on environment variables such as process.env.NODE_ENV.

EDIT: It just occurred to me: Were you doing window.GLOBALS = ... in a file and never actually requiring it anywhere. In that case WebPack will never visit and process that file. It must be either required/imported somewhere in webpack’s parse tree or a separate file chunk linked as an entry point in webpack.config:

entry: {
  ...
  globals: 'globals'
}

I’ve never actually used it like that and it’ll result in an extra <script> injected in your index.html, based on your config, of course.

#6

Thanks Velenir, just came back to post and saw your response. I like this idea of keeping the globals in their own file. I’ll adopt this. Yes, I think I was doing window. without requiring it!

I have now got a working two file system. a helpers.js with a couple of functions and a couple of global vars (used in app.js); all four of which have ‘export’ prefixed, and in the app.js file I have "import * as helper from ‘./helpers’ ". Webpack squishes the two files and spits them out into ./dist/bundle.js, which is referenced in the script tag in index.html.

The only annoying part of using webpack now is that any errors in chrome console now show as “error in bundle.js line 854” or whatever, so I have to first look in bundle.js for where the error is located, and then go to the app.js/helper.js to start troubleshooting and make the relevant change. I don’t know whether this is just a tradeoff or whether I’m approaching my development setup in the wrong manner.

Cheers,
Tim.

#7

You can enable sourcemaps (mappings of original code => resulting bundle) by including devtool in your config. I use devtool: 'source-map' in production and devtool: 'eval-source-map' in development.

#8

Ahh, wow, didn’t even know that was a thing. Just enabled and it fixed that issue. Velenir, you’re my hero! Thanks.

#9

We all live and learn, Tim. And learning WebPack is especially complicated by the kind of documentation available and a lack of thorough enough tutorials. On that note allow me to recommend the tutorial that cleared up a lot of points for me - SurviveJS.

#10

Thanks for that, I’ll have a read. I just posted a quick how-to on the forum for others and referenced your help with it.

Thanks again.

Tim.