As of version 2.12 it appears that the dynamic import of the server-side module no longer invokes Meteor.startup once the module is loaded. Is this a new feature or a regression?
stuff.js
Meteor.startup(() => {
// ...not called;
});
main.js
if(something) {
import('./stuff.js')
}
On the client side, dynamic import is suppose to break the JS bundle into smaller pieces and fetch them as needed if a dynamically import component or module is not already on the client.
I am curious, what would be a reasons to split code on the server?
Meteor startup by nature is supposed to run as early as possible and I am not sure it is supposed to stay behind a dynamic import.
The same application can be launched in different modes with services that can be configured during start-up and loaded dynamically. Until version 2.11 everything worked, now the system does not start because the startup process of the dynamically loaded modules is not invoked. I do not understand what could have changed since the callStartupHooks is the same.
ok, I can confirm that when I put my startup file import behind a condition (just like you do) everything works ok with 2.12.
I suggest you console.log something right before the import to make sure something is true. And then you can put the import behind a constant such as const test = import('./stuff.js') and console.log the typeof test to make sure it comes as object and not as Promise. You can await it in case it returns as Promise.
Basically … it cannot … not work.
Thanks @paulishca.I have already made these attempts without success. I have noticed, however, that the problem occurs when I have nested Meteor.startup calls and some of them with an asynchronous callback. I will try to revise the code to eliminate startups in dynamically imported modules, as they should not be necessary.