So lets talk about improving the mess that is modules/imports.
My general take is that imports are 8 steps forward in terms of functionality and 5 steps backwards in terms of usability. That’s a net improvement of like 3 steps. But the overall traversal distance is 13 steps. And net 3 benefit versus 13 effort… leads to a lackluster ‘eh’ in terms of excitement in upgrading.
Now don’t get me wrong. I recognize that import statements are something of a gold-standard in programing languages, and for good reason. I had an entire career in C# where Import statements were de rigueur. So I’m not scared of Import statements.
But I also know that VisualStudio had Intellisense that could parse through all the available namespaces, and adding Imports amounted to selecting through drop-down menus. I also know that VisualStudio had refactoring tools that could move files, and that relevant path names would get updated. Which makes using the new imports that much more painful… because it’s obvious that there are missing tools for managing them.
So, what are the biggest pain points? After using imports for the past month and getting up to speed on how they’re implemented; the biggest pain-point is moving files. One of the major benefits of the pre-1.3 releases which autoimported into the global namespace, is that the resulting user experience was one where a dev could effortless rename files and move them around to work out the best application structure. One could effortlessly optimize naming schemas and organization systems.
With the current implementation of imports, however… once a few import statements get written referencing a file, it quickly gets entrenched and becomes difficult to move. Which leads to files not getting renamed to reflect content and purpose; of files not being moved to logical groupings; of file fragmentation. It’s a total mess. And let’s not get into the problem of missing modules and modules-not-found. We’ve traded the occasional intractable file-loading problem for an order-of-magnitude more missing-module errors. Which can be a blocker for junior devs or folks new to Meteor. (And one wonders why user experience and satisfaction is plummeting.)
So, what can be done about all this? Well, after a month of using imports, I’m convinced that we need file move/refactor utilities that can scan the file system, intelligently build up a map of all the files and import statements, and intelligently refactor the import statements. Just like VisualStudio used to have.
Questions are: do these utilities exist already? In NPM? In Webstorm? In Atom packages? If so, how do we incorporate them into existing documentation and builds? If they only exist as command line utilities, how do we incorporate them into the IDEs? If they don’t exist, can we marshal the resources to build these tools? Who’s interested in working on a utility for refactoring import statements?
Any thoughts or opinions or links would be much appreciated. I’m in import hell right now, and need a refactor/move utility badly.
All the relevant Atom package links that I can find or have been discussed in this thread:
And relevant GItHub issues: