[ERROR] Identifier Meteor has already been declared

[elmarti]

• Occurring in Meteor 1.7.x
• Did not occur in Meteor 1.6.x
• Present on Ubuntu and Windows 10

In my elmarti:video-chat package, I previously had both app.addFiles and app.mainModule calls for the same file in package.js, I may have done this through lack of understanding, but it now causes the file to be bundled twice, meaning that there are duplicate let declarations.

But now this seems to cause the non-fatal error
[ERROR] Identifier Meteor has already been declared

[elmarti]

Removing the import { Meteor } from 'meteor/meteor'; in meteor.js seems to fix this particular issue, but then causes the same thing for MeteorClient.. is module scoping broken?

[elmarti]

Alright, I seem to have found the issue, it was using api.addFile and api.mainModule for the same file, which now causes the code to be added to the file twice, causing variable name collisions.

My guess would be that the modules appear to be loading asynchronously now, so it allows the browser to resolve the modules at runtime, whereas I assume before, the compiler picked up that the same module was being loaded twice and dealt with it in its own way.

I won't close, on the off-chance you want to give your opinion

[elmarti]

BTW, DI pattern was a red herring, this is a general bundling issue which has brought a sleeping bug to life, rather than something specific to my design pattern.

[benjamn]

I believe the reason this started happening in Meteor 1.7 is that the modern bundle now compiles the import { Meteor } from "meteor/meteor" down to a let declaration instead of var, and you can't have two let Meteor declarations in the same scope.

In any case, it seems like a bug that adding the same file with api.addFiles and api.mainModule results in multiple copies of the module, since those api method calls should just be idempotent.

[benjamn]

I've added a warning about duplication between api.addFiles and api.mainModule. There was already a warning in api.addFiles, so it was just a matter of adding the same warning to api.mainModule. Hopefully this will help catch similar problems in the future!