Refactor/move file utilities with Meteor 1.3 Imports

core
41

The leading slash is a Meteor thing. My experiments led me to the exact same point. The namedExports gets around the “/” problem in addition to using the import syntax I like, but creates another maintenance issue.

I found that Cmd-Shift+I worked as long as I didn’t ask it to find any packages. i.e. if I deleted a line importing one of my methods, it added it back with no problem. But, if I deleted the import of SimpleSchema or Meteor, it gave me an exception.

Following a hunch, I defined namedExports for all of the packages that one of my modules used and Cmd-Shift+I then worked fine.

So, this is quite usable if you go through your .meteor/packages file and define namedExports corresponding to every package. But then, that seems to defeat some of the purpose.

I’m just in my initial stages of trying to understand the code, but thinking that this needs to be altered to parse and use the information from Meteor’s .meteor/package, .meteor/versions, and package.js files in the same way that it already parses package.json files. It also needs to support Meteors absolute path implementation so that we don’t have to define namedExports for our modules just to get paths right. And it needs to know what a “core” meteor package is in order to perform the grouping.

One thought that makes me hesitate to do a whole lot on this is… how much of these problems will go away in 1.5? The “/” thing, probably not. And it wouldn’t go away for legacy packages. But npm packages should work fine with this out of the box.

Maybe, due to the legacy package issue (they might be around for a long time), it’s worth customizing this to support them.

Anytway, it appears to be a promising starting point!

1 Like
42

It looks like needing to define namedExports more easily is an issue that goes beyond Meteor. They have an applicable issue, Auto-resolve named exports from ES2015 modules.

Looking at it, parsing all files to find the exports every time a user changes something in the editor is, of course, an issue. So they are talking about having something that does it once and then could be re-executed when needed. The details of finding the files could still be different.

I wonder if there is some by-product of the meteor build process that could be farmed to get this? That would have the downside of requiring a build to get the first version, but that’s not a bad downside. I usually do my first build before writing the first line of code.

1 Like
43

With import-js, eslint, and absolute paths, I feel like I’m finally getting a handle on refactoring imports. I’ve gotten to the point where I can rename a file throughout the application in five steps:

Ctrl-Shift-F
> old name
> new name
Right click > Rename
> new name

A far cry from drag-and-drop functionality. But workable.

1 Like
44

Just a week ago I submitted this feature request.

It didn’t get any votes. Maybe I’m not clear enough on what I think is a simple solution. Build a map of files and allow for “i dont care where it is” referencing by using an operator like tilde or other.

What do you think?

best
Jesper