meteor-client-bundler
meteor-client-bundler copied to clipboard
__meteor_runtime_config__ is not defined error has returned.
Uncaught ReferenceError: __meteor_runtime_config__ is not defined
at Object../src/module/meteor-client.js (meteor-client.js:1)
at __webpack_require__ (bootstrap:84)
at Object../src/main.ts (main.ts:1)
at __webpack_require__ (bootstrap:84)
at Object.0 (clubezy-models.ts:84)
at __webpack_require__ (bootstrap:84)
at checkDeferredModules (bootstrap:45)
at Array.webpackJsonpCallback [as push] (bootstrap:32)
at main.js:1
Currently using Angular 8 and Ionic 4 on the frontend, connecting to a meteor backend using 1.8
my bundler.config.json
{
"runtime": {
"DDP_DEFAULT_CONNECTION_URL": "https:--------.com",
"autoupdate": {
"versions": {}
},
"release":"1.7.0.5",
"PUBLIC_SETTINGS": {
"env": "development"
}
}
},
"generateNodeModules": true
}```
I'm happy to assist in creating a PR to fix this, but I'm not sure where to start.
Same problem for us after upgrading an Angular 7.2 client to Angular 8 (also Meteor 1.8 on the backend). It worked without problems beforehand.
Im somewhat guessing it is due to the compilerOptions
in tsconfig.app.json
which require the module
flag commonjs
or esNext
for Angular 8 to work but would require es2015
for the bundled meteor client to work.
PS: If there are better maintained alternative packages which do work with Angular 8 we would also appreciate a tip!
Ok
I've been playing around and I found that my ng serve
was working locally.
I also found that if I did ng build --watch
and then served the result from the output dir, it would also work.
This got me thinking that angular 8's differential loading could be whats causing the issue.
I changed my browserlist to > 5%
which only outputs a single set of files (which are es2015)
This seems to be working correctly for me for now. (ive only checked with chrome also, might need to test with other browsers)
my tsconfig has module:esnext
target:es2015
.
Hi, I'm running through the same issue here but don't understand @Slavrix tip. Can you please give more details on how to "change browserlist value"? Thanks
Ok found it!
(should have looked better 😁)
So there's a file named browserslist
at the root of the angular project, this is the file that needs to be limited to
> 5%
And it did indeed fix the issue!
Thanks a lot.
And this is back again with an angular 13/ionic 6 project with meteor 2.5.1
@Slavrix did you find any solution?
My browserslist
(in package.json
) is still set to > 5%
but it fails when trying to upgrade from Angular 11 to Angular 13.
I haven't been able to get it to work yet with angular 13 still working with angular 12 though/
Ok, I have tried to start having a look through, and I think that for some reason, how angular 13 is importing meteor-client.js it doesnt have access to setting globals (or something like that)
I went through and was able to get the __meteor_runtime_config__
to work by doing this
if(window.__meteor_runtime_config__ == undefined) {
window.__meteor_runtime_config__ = Object.create(null);
}
window.__meteor_runtime_config__ = Object.assign({
"meteorEnv": {},
"DDP_DEFAULT_CONNECTION_URL": ENABLE_DEV ? DEV_URL : DEFAULT_URL
}, window.__meteor_runtime_config__);
see the added window.
This then opened another error further down (around like 200ish)
where it couldn't set global.Package = new PackageRegistery();
I did the same thing to try and get further.
console.log(window.global);
console.log(window.global == undefined);
if(window.global == undefined) {
window.global = Object.create(null);
}
window.global.Package = new PackageRegistry();
I was able to get further now but the next stopper really is what is stopping me now.
around line 400 if(!global.setImmediate) return null;
this now catches me.
global here is set just above it as var global = this
and that is what has now stopped me as i cant workout the context that the this is currently in to get deeper,
I added some debugging here to see what the this was, and it just comes back as undefined
.
I was going to experiment with trying to bundle meteor using different tsconfig setups to see if that made any differences with how the file builds, incase that helps
could there be something to do with how webpack is loading this file or something maybe?