Yeah as I said it’s harder for beginners, I know that. However for me, I had to get two other devs up to speed on my project, them knowing JavaScript, it was easy, they didn’t have to know Meteor. When 1.2 was around it took me a day to get someone up to speed with how everything worked and all the little details of Meteor, like the nested folders for build order. So I guess it’s an interesting one, experienced devs it’s probably easier than ever to start, beginners its harder than ever.
@joshig As you say it may not take long to write import statements, but keep in mind this is not Meteor’s traditional method. So what about the projects with thousands of files that do not have import statements? How much time do you think that will take? Might there be some issues with this in the future when backwards compatibility gets dropped, where developers would try to go as long as they possibly could before they do the upgrade, to avoid the lengthy job of upgrading a huge project to a new import system & folder format? What about when an update with vital security updates or something along those lines is released?
I think it’s great that they are building a world class platform. I do not think it’s great if they “sell the soul” of Meteor in order to become suited for larger projects. Meteor was built around fundamentals which are the reason most of us are here. Why should it even be an issue that some of us want Meteor’s future to be built around those same fundamentals as well? If you take those away, it’s not really Meteor anymore.
Especially on an issue such as this, where many projects (even my largest one) doesn’t actually require it and will see little to no gain from it? When adding support for “the old way” shouldn’t really be too difficult of an issue, as functionality similar to it is commonplace for plugin’s in some major IDE’s anyway.
And regarding getting devs up to speed… My job actually hired some frontend devs. They were somewhat familiar with javascript, but not specialized in javascript. This would have been completely sufficient pre-1.3 - and it’s a shame because I instructed them to put that as the requirement on applicant’s resume’s specifically because of Meteor’s state in 1.2…
But they started about a month after 1.3 dropped. The official tutorials also got much more difficult at the time, and even the folder structure was completely different from our huge project that they were going to assist me on. So I had to teach them Meteor (the way our work project uses it) from the ground up myself. It was a very unfortunate inconvenience that things changed that way after they were accepted for the position and right before they started.
I personally hope the day does not come where I have to go through the whole project and spend all the time restructuring it manually, for features that do not benefit the project. How do you think that will look to management in plans/progress reports? Definitely not time well-spent. So I am sure it will run in to that problem I mentioned earlier, where it will be pushed back as much as possible.
I do agree it’s a problem if you’re trying to update from 1.2 to 1.3, but my guess is from MDG’s standpoint, that’s a very short timeframe problem. It’s a bit like when everyone freaked out when Apple decided to change the iPhone cable, everyone panicked for a few months, but now a couple of years on, no one cares, but everyone is glad they did.
I honestly think clinging onto the past while JavaScript rockets forward is a mistake, and I’m glad Meteor is supporting the wider ecosystem. So yes, I feel for your situation, it does suck. I’m in a similar boat with some Angular 1.X apps that we want to migrate to 2.X. Or old react apps before the split from React to React + ReactDOM. That’s life, though, all those systems have improved massively, even if they do hurt a few projects in the short term.
I’d say if you’re happy with 1.2, stick with 1.2 for those past projects. Move to 1.3 for new ones. In production, you ideally shouldn’t jump to update everything for every release, unless there is a major new feature you need.
That would be fine short term, but long term I am less worried about new features (I’m pretty satisfied with features), but more worried about any critical updates to vulnerabilities/security/etc.
@joshig the main problem is not the imports, it is the refactoring hurdles that come with it. Yes properly structuring the code beforehand and creating module based facades are two most basic things that should be implemented anyway. But, every app comes to a point (even within days/weeks) where names should be changed, files should be moved or split and javascript editor/ide offerings are far less than complete in terms of refactoring support. Even reportedly successful refactorings turn out to miss a few things, thus introducing subtle bugs or more overhead.
But yeah, this certainly is a move forward, but javascript’s (and Meteor’s) “move” does not always feel that forward. Or it does not feel well executed.
In fact, javascript/meteor move feels so sporadic and backwards-problematic that I strongly disagree with this statement:
In production, you ideally shouldn’t jump to update everything for every release, unless there is a major new feature you need.
Because you never know if two minor versions ahead, you’ll be left so behind that it would become impossible to even publish hotfixes due to any one of javascript core, meteor core and any library/package out there having abbandoned support for your deployed version. So you are kind of forced to keep up and even ahead.
Thank you for this excellent breakdown of the current state of refactoring in Webstorm. These are exactly the type of issues I was hoping to discuss in this thread.
Suffice it to say that Atom is basically in a similar state, if not even a bit further behind. Atom has a quick-move package, which doesn’t look at imports or file content at all. It has a refactor package which is a glorified version of ctrl-D multiselect, but doesn’t handle files. There’s no drag-and-drop. Files can’t be quickly divided. Not sure if moving a file would trigger a reload in the jsimport package, but the cynic in me guesses that it wont.
The bright side, however, is that with Atom we have the source code to all these packages (and more). So we know how to build up the imports map using jsimport. We know how to create the IDE menu selections using quick-move. We know how to search for import statements using refactor. Getting a working file-move refactor utility in Atom is doable by the community.
Excellent questions. The cynic and realist in me expects it will fall to the community.
Although I would like to state for the record, that there is a fairly large group of experienced devs in the Meteor early-adopter community, who view Meteor as the most sophisticated refactoring tool in the Node ecosystem. Meteor has historically attracted junior developers because it let them build Node apps without having to manage Node require statements; and moving files around and the build system watching and rebuilding automatically amounted to magic. However, that same build system has also attracted senior developers because they see it as an entire refactoring pipeline with filewatchers, file scanners, autoimports, file writing, etc. And that refactoring pipeline has to be rebuilt as of Meteor 1.3 to accommodate ES6 import statements.
So this is something that MDG has historically owned. Whether or not the choose to continue owning it… I got no clue. But this isn’t something new or some type of feature request. This is very much a core feature of the build system that’s been around since 0.3 or 0.4 days that’s possibly being removed, if the guide and statements about imports being the default in future releases are any indication.
[quote=“seba, post:11, topic:25176, full:true”]
Yeah, especially if you split up your app in multiple packages, it becomes very hard to move files around. And no editor knows what to do with ‘meteor/…’ imports. For packages you publish publicly it becomes almost impossible to refactor.[/quote]
Another great consideration. We’re definitely getting enough to create a bullet-point list of recommendations and an action-list. Will need to add meteor/.. imports to that list.
This should be a recommended best-practice in the guide and in example applications. Thank you for pointing this out. There’s a world of difference between absolute and relative paths in import statements; and I’m beginning to get to the point where I can’t see anything good about relative import paths.
# GOOD
api/ui/startup/utils
# BAD
./style
# REALLY BAD
../../../../../api/etc
I know for a fact that the Meteor Chef Base app is currently shipping using relative paths. That’s how ./style statements crept into my current app; and it’s slowly-but-steadily spiraled out of control into import-hell.
And looking outside the Node community, the C# and .Net community uses qualified namespaces, which are basically absolute paths.
So, can anybody think of a situation where relative paths are essential? Meteor packages? Npm packages? Otherwise, I think there’s a case to be made to update the Meteor Guide and various styleguides and best-practices to use absolute paths in import statements.
So, can anybody think of a situation where relative paths are essential?
I think we should move away from packages anyway, (since we are embracing imports) so that’s no longer an issue for the long run, but here are my pet peeves:
since meteor accepts imports from the imports folder only, and that’s not a top level project folder, all imports have to begin with /imports/ (or imports/ if it is to be considered a special imports root, per the build system (meteor) configurations)
at least webstorm gets confused with absolute paths. when I tried it, it completely lost the ability to resolve module exports properly. this leads me to think that absolute imports
absolute paths may mean different things depending on the environment (browser/node), you may even end up trying to read from the file system root!
it is also different from the perspective of the build system. for example, typescript and es6 treat paths differently (so I heard)
Anyway, if we actually do find out that using absolute paths is working fine, I’d still use a mix where files enclosed in a module use relative paths between each other and modules import from each other using absolute paths. Combining this with index.js files that rexport from the module’s private files, we’ll get a proper structure which we can later than have the ability distribute as public/private npm packages as well.
I second that. I’ve been watching this thread wondering why everyone has found it so difficult because I haven’t felt that way. One of the answers is that I used absolute paths for everything not very very closely related to the module I’m in. So, for example, if I’m in /imports/api/groups/methods.js and I need to import something from the users api, I use the absolute path, ‘/imports/api/users/users’. But, if I’m importing something else within the groups api, I use the relative path, ‘./groups’. This has made it easy to move whole groups of associated files around and just do a global find/replace on the path.
Of course, I started using modular languages 30 years ago and had no IDE support for at least the first 10 years - never really got used to the refactoring tools.
My perspective on the wisdom of introducing imports goes like this.
We’re moving to NPM as a packaging system, a move that will open doors both to the Meteor community to employ and deliver more packages to more users and to the NPM community to benefit from more of Meteor’s goodness.
NPM currently uses “require”.
We were fixing to have to start using “require” all over the place and encounter all of these problems anyway.
But ecmascript has already decided the winner in the war amongst systems for modularization and chosen “import”.
Everyone, including NPM, will eventually change to “import”.
Ben has given us a wonderful gift in that instead of moving to “require” and then having to shift again to “import”, we can jump straight to “import”. I applaud the timing of this! It had to happen and better now than later!
Furthermore, by implementing it as an NPM module, “reify”, he is bringing “import” to the whole NPM community, now. Note also that he was careful in his latest “reify” code to extend the ecmascript just a little, in a way that NPM absolutely requires, so that it can FULLY replace the “require” syntax. i.e. the latest versions allow import to be used in conditional and nested scopes. No more "require"s required.
All of this and other changes coming in 1.4 and 1.5 puts Meteor in the position of entering the NPM community on the bleeding edge instead of the trailing edge.
When at the bleeding edge, development tool pains always occur. We simply need to be as proactive in pushing the tools as MDG has been in pushing Meteor into a position where it can join the larger community and pull it instead of dragging it.
I am right this moment spending a portion of my time trying to get modifications introduced into at least one of the parsers that ESLint uses, either espree and/or babel-eslint, so that conditional and nested imports don’t cause parsing errors that kill all analysis of the modules containing them. i.e. I identified an upcoming problem that will effect not only our community but anyone in the NPM community using ESLint and Ben’s “reify” package to replace “require” with “import” and I’m working to fix that problem before people see it. I’m not an MDG employee, nor is anyone paying me for any effort I’m making today.
So, I applaud everyone on this thread exploring what WE can do to move development tools into position and hope that this discussion will result in solutions that can be put in the guide for everyone’s benefit instead of requests for someone else to do something. If you can’t do it yourself, you can still help greatly by searching for things that are open source and close to what is needed (as I’ve seen some are doing) or brainstorming positive ideas that might give inspiration to those on here who may have the skills and time necessary.
Well, actually I use it a bit more nuanced than I first said.
I do use relative paths for files I know will always reside in the same directory. Like index files and my scss and template imports of my angular components. And a disadvantage as @serkandurusoy also points out is that editors don’t get absolute urls. But that last problem might disappear if we completely move isopackages to NPM packages. But we’re probably still quite a bit away from that.
You are absolutely right in all of your assertions that the contents of the “module-name” in the imports syntax were not specified by the committee. Every build tool has the freedom to interpret it differently. I believe though that Meteor and NPM both will be using it as relative to the app or package directory. We just need to get our tools fixed to support our build system’s interpretation of “module-name” which I don’t believe is unusual.
Note that ESLint was at first marking absolute paths as unfound and a fix for that system is already available in the form of the NPM package “eslint-import-resolver-meteor”. I have submitted a PR to the Guide to add this.
Btw, does somebody know if the name of the index file is configurable?
I’d like to name it _index.js (so prefixed with underscore), that way it would always show up at the top of my directory in webstorm (and most other IDE’s).
which uses babel-root-slash-import but that’s still confusing because .babelrc was not supported with meteor back then. Does it perhaps use a different build system like webpack? What gives?
That’s where I’m confused too, they don’t use any other build system. There is a webpack example, but I’m not using that and most projects I’ve seen don’t use that unless they really want HMR.
Either way, I’m not using /imports/ and don’t seem to be running into any problems at all. Based off that kickstarter though. It’s a topic I’ve always been curious of. I did find this: https://github.com/kadirahq/mantra/issues/172 it seems Meteor is still loading itself, but following the import paths provided if available?
@joshig, apart from the issue @rlivingston dug out for us (thank you buddy) a simple
git clone https://github.com/mantrajs/meteor-mantra-kickstarter.git
cd meteor-mantra-kickstarter
meteor npm install && meteor run
has a host of issues with dependencies etc, so I could not even get to a point to properly test if the imports work!
But, I did try out importing a file (template.html) located outside the imports folder a few days ago only to see the server crash with a module not found error and that was when I found out about the imports folder not being optional.
As someone working on a small minimalist app, I feel strange having to refactor by adding lines of code with no immediate benefits, in the form of import statements. I remember when the first meteor tutorials prided themselves in having very few lines of code.
When imports become the default, it would be nice to add an ‘eager’ folder so we don’t lose that functionality, or an ‘eager’ prototyping package just like autopublish/insecure.
