Ember's conventions for project layout and file naming are central to the developer experience. It's crucial that we get both the technical and ergonomic details right. I wanted to provide an update about Module Unification and our plans for the file structure in Ember Octane.
Thanks for this post. There are some like this: strings missing from the text. (On the discuss.emberjs.com copy)
We can skip resolving components through MU altogether, and let Ember users organize their component files however they want.
Is this not one of the selling points of Ember, structure? I feel like value will be lost of the default becomes “put your files wherever, just make sure you import them”. Sure, while you can tell were the file is by looking at the import path, it (potentially) won’t be easy to just scan the filesystem for a component, service, etc.
Yes, I totally agree. Our intent is not a total 180° change in philosophy here, where we switch from the classic file system layout to the “YOLO” file system layout. One of my favorite things about Ember is that I can drop in to one of our 200+ Ember apps at work and be productive in a few minutes, in large part due to the consistent file system layout.
This is not locked in yet, but what we’ve been discussing is the idea of a linter for file system layout. (I’m bummed out the npm package name fslint is taken!) I think this is something we could build in an agnostic way that would be useful outside the Ember community.
The idea here would be that, similar to other linters, there would be programmable rules about which files belong in which directories, and you’d get a warning in your editor or build output if you e.g. put a component in the services directory. Rules could be customizable, so we could build a set of standard Ember rules that are included by default in new Ember apps, but you could also write a set of rules for create-react-app, or custom rules for your Ember app on top of the defaults.
The nice thing about this approach is that people seem to understand intuitively that a linter is a suggestion that can be disabled or selectively overridden if it’s not providing value. And by decoupling the file system structure from how the application behaves at runtime, we can provide a strong nudge towards shared conventions while still letting you rearrange your file system without breaking your app if you really really want to.
Are there any merits to solving similar to how, say, Svelte solves for it?
js
import UserRow from '../components/user-row';
import { List } from 'some-ui-list-package';
export class Users extends Component {
components = {
UserRow,
UserList: List
}
}
hbs
<UserList>
<UserRow />
<UserRow />
<UserRow />
</UserList>
I also think that “the conventions” are one of the main selling points of Ember.js. But for components, there are no real conventions. All the components are inside the components folder and that’s it. There is no convention inside the components folder. I like the idea of combining imports with some linting logic. In the modern JavaScript eco-system imports are everywhere. I also work with Three.js and it’s interesting how they use existing tooling to include glsl shaders into their final JS bundle. If someone interested here is the code:
It’s just a short rollup plugin. Since they use rollup they could (actually they do not do it) use the whole power of rollup (which means code splitting, dynamic imports etc).
We also work with Glimmer.js a lot and one of our most successful products is build with Glimmer.js but I can totally agree with @tomdale that some trivial stuff, (like it’s menitoned in the blog post under the section “A Personal Anecdote”), was really hard to achieve. We had to fiddle around with default-module-configuration.ts and so on.
I also worked a little with Vue.js and Vue-CLI-3 and I really liked their approach. Everything is an import. If you want to lazy load something you just use a dynamic import and tooling takes care of the rest.
Nevertheless, we decided to build our newest project again with Ember. We like the conventions and the guidelines from the community and the freedom Vue.js gives you seemed to be “dangerous” to us. Just because it’s simple to build a proof of concept it does not mean that it’s simple to build a production-ready app.
We are really excited about the future of Ember and we hope that "Eventually all the good ideas will end up in Ember".
Thanks for taking the time to write this post - especially when you must have a million other things to do, including the upcoming EmberConf.
The explanations and historical perspectives help a lot. And overall, it is just extremely well written.