I’m writing this here because I’m really struggling dealing with my legacy Meteor Packages, you know the package architecture us Meteor Heads promoted a long time ago. Since the change to imports writing new code that needs to be called in a legacy package is proving to be REALLY problematic. Am I the only one who feels this way?
Is there a way to import from the imports directory to a Meteor Package?
I opened this issue awhile ago
But didnt really get much attention. Anyway! Let me know!
We’re having the same issues… MDG has been great when it comes to backwards compatibility but transitioning a large app from a package architecture to an imports architecture is very difficult.
I’m thinking it might be possible to move some “top” packages, without other packages depending on them, can be moved to /imports, but at some point it get’s really messy.
So not sure if there’s a nice way todo this without support for local packages to import from the root of the app.
Maybe just change /packages into /imports and spend a week or more to clean up imports everywhere…
Edit: A more possitive title might be: “Migrating from package architecture to imports architecture”. Although the current title is a better click bait
As far as I can see Telescope uses a purely package based approach. Also I think it would be quite astonishing if Sasha managed to import modules in packages, because from Ben’s comment here it seems that this is atm just not possible (https://github.com/meteor/meteor/issues/7704#issuecomment-242175930)
I don’t know what to say other than after looking at the source you see imports being used for what appears to be everything within a package architecture with exports being shared across package boundaries etc.
Yes telescope uses the modules package to export namespaces for other packages or your app to import. What I’m specifically talking about is having a Meteor package that is in your packages directory trying to import a module found in your imports directory.
The current workaround for me is a hack.
I attach my modules to a global variable and rely on it being “available” to functions in my packages after Meteor startup. super brittle
That sounds like defeating the purpose of having something as a package. Wouldn’t it be the same as code from node_modules importing a module from your app source?
Though I’m unaware of all the constraints of your project, but normally I’d look to do one of the following in your situation:
either refactor the app module in imports to convert it to a package.
or, if the package needing that module doesn’t need to be distributed via a package manager, then refactor it to be an app module
About point #1: maybe only parts of the module need to be converted to a package. In the past when I’ve faced such dilemmas about dependencies, it turned out that the module in question has low cohesion and needs to be refactored to extract the more generic parts.
I know it doesn’t address the question, but all I can say is that the all-package-based architecture works great with import. In fact I’m thinking I’d keep the same architecture even if Telescope wasn’t a Meteor app, maybe using Lerna.
