I am gradually porting my app to ES6 import syntax and have some Atmosphere packages which export global variables via
api.export().
Importing these variables via import works fine. However, as soon as the packages are nested and an Atmosphere packages re-exports an imported package via api.imply(), I cannot import this variable via ES6 import. Is this missing or am I doing something wrong?
I’ve not tried this, but I suspect this is just the way it works and is probably a hang-over from Meteor classic. The way to get around this was to explicitly meteor add package-name which gave application access to the package global. I think that will still work and you’ll then be able to import.
1 Like
Yep. But this does not work for my use-case. The implying packages are my own local packages which I want to keep modular, so they define which packages shall be effectively included in my app. If I add them directly, I am losing part of this modularity.
1 Like
BTW: I just found out that this also hits you when you use some popular packages like useraccounts. For instance, I am using useraccounts:flow-routing in my app. If I try to import the symbol AccountsTemplates from this package, I get an error. This is because the symbol is exported by useraccounts:core which is implied by useraccounts:flow-routing.
Problem is here, that you have to know “magically” the dependency between these packages. And your code might break if this dependency changes in the future. Wondering if I should file an issue for that.
It’s probably worth finding out if there’s a canonical way to address this.
1 Like