I have my concerns about this because you’re basically giving plugins then on the hand of many where not everyone is cooperating with everyone else. You can easily have people who “just want to fix something small” and start pushing out a new version as they please etc.
Maybe it’s a part of my german culture, but I like if someone is responsible for things. This is also why (in my eyes) packages should have maintainers and not just be “at the community”.
I’d rather personally pick up packages which have been abandoned and ask the author to get access to github and atmosphere to publish new versions on their behalf - or join groups having packages which are related to each other (like the meteor-testing group).
I’ve also started forking packages and pushed out a notification in this forum about it and in the ticket system in case the author was not responding to my request (either approving or denying - but just keeping silent) for weeks or sometimes even months.
I know I will lose the battle in advance because you all chose the ‘community aspect’ first and my opinion is unpopular.
I will share it still. Maybe some people will stop being dogmatic and actually listen
I argue that there should be the choice: all fine for current imports system. Let’s keep it.
The concept of automatic imports should be pushed further.
This is so handy for small teams, and for prototyping ! Which is where Meteor (used to?) shine
The automatic import system is still working, but now it seems to be covered with dust and didn’t get proper attention recently.
Having a system to fine-tune load order easily as I suggest would dramatically simplify the codebase for small projects.
Being able to control load order means that the most important scripts will be loaded first and I can control that easily as well.
I just thought this was a nice option, especially for beginners. God it seemed so easy to get started on Meteor before, but since imports are a part of the Meteor tutorial, I see a lot more complexity from a beginner’s point of view.
No worries. When systems scale, it becomes hard to chose what goes in and what not. For this reason its good to look at what users want. It probably seemed like a good idea to go import based, because the auto import version had issues regarding scale.
Unfortunatly this decision also impacted the entry level for new devs and prototypers
I have a huge problem with that, since the file structure is the number one thing that makes a codebase understandable and clear. I’ve been dealing with having to prepend my filenames with numbers, just because I needed to gain control over the load order. Alternatively I’ve dealth with writing atmosphere packages that wrapped my app code just because in those packages I did have control over the load order.
I want to ppint out another thing. Learning curves are not a bad thing. They need to exist in order to make developers better. Not using imports and all of its benefits removes part of the required skills to properly structure applications and opens the next curve towards learning about NPM and dynamic imports / code splitting
You learn to become a better programmer. Better in this case means knowing why imports are a good thing compared to all the issues described by @cloudspider. Writing those lines of code are good, because it solves an issue. It won’t save you time and productivity in the long run if you skip learning those steps.
You could also skip writing tests and be more productive at the start, but you’ll pay for it later.