Sessions is temporarily moving to YouTube, check out all our new videos here.


Adrian Zalewski speaking at EmberFest in October, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

In this Lightning Talk, Adrian will show us how he built eslint-plugin-glimmer.


Hi guys, Today I'd like to present you with eslint-plugin-glimmer. There is still not much to show actually. It has been developed last night. There's actually a backstory associated with it. This is me, by the way. I'm Adrian, I work at Netguru. You already saw it yesterday. When I gave a talk about linters and how we can use them in Ember, and I created this joke rule for CFP for Ember conferences. You have to mention one of the keywords to be accepted. Fastboot, Progressive Web Apps or Glimmer. I ran with so few guys that I forgot about. In this case it was Glimmer. And there is a case study. My presentation CFP "Promoting Ember's best practises by linting code." It went to EmberCamp without any mention of Glimmer or Fast Boot or Progressive Web Apps and it went to EmberFest exactly ... I mean it was the same, word for word, except for one last sentence, which was, Finally, I'd like to tell something about the future: meaning Glimmer, blah, blah, blah. And plug-in for Glimmer. And it got approved. It was basically inspired by my talk with Jacob. We're examining the CFP and we'd said something like, Yeah, it's pretty cool CFP. It's very interesting, but there's no Fastboot there, and no Progressive Web Apps and it would be really nice to mention Glimmer or something. So, coincidence? Yes, it was. There is nothing deeper behind it. But, that's how the idea of eslint-plugin for Glimmer was born to cover Glimmer components. And, linting rules, to think of linting rules for Glimmer is actually not so easy. We tried to do this, well, last night. First of all, Glimmer is still a work in progress. There are still changes in the API. There are no community style guides for Glimmer components and there's not that much to talk about, as well. Limited functionality scope. It's just components. There is no Ember data, no roots, nothing. And, finally, there are no depreciations to lint against because it's all new. So, yesterday there was this last free spot for Lightening Talk and I had no idea what to talk about. But I was like, you only live once. I will lock myself in. And, in the late evening, I got to say, we had to actually write eslint-plugin-Glimmer. We have looked, with Michal, who was just talked before me, into some rules in current eslint-plugin-ember, which, by the way, was also created by Michal So Whoops. Well, they don't really fit Glimmerjs. For example, we have new-module-imports rule. It doesn't make sense in Glimmer because we cannot truly import Glimmer the old way, at all. We cannot use, and we don't even want to, if we could use Ember getters or setters. We just have native EF6 classes and their properties. We have no roots, no router and so and so on. But we thought of some rules that we could actually implement. And yesterday, well, last night, this was published. It already works, has, like, nice rhythmic contribution guide. It's zero to zero on npm, which is a lot for one night. And that's a different story. So, I will just show you two rules that I implemented so far. A word of warning. One of them, the next one doesn't make sense. So, this is the first one, no-side-effects-in-tracking-getters. If we have getters that are tracking some properties, it doesn't make sense for them to actually modify properties of the component in any way. And this rule highlights when this happens. And the assignment is detected at this time. Other limitations like pushing to Aries, not yet. This is the good way to approach this. It's basically the way to mimic how computer properties behave in Ember components. And the next one, it doesn't make much sense. It's there, you can use it. And it makes sure that we call super-in-constructor of the Component. It doesn't even check if this class is a Glimmer component. And this is something that is not even valid JavaScript. Of course, the idea was to mimic the warning that comes up in Ember in ad-hoc. But, it doesn't make sense, don't code at night. It will have to be removed. We have some proposals of some more rules created by Michal. They are pretty cool. This is my favourite, no-tracking-untracked-properties. Something that you will have a console warning anyway about, but it's still nice to have it yeah, to see the error there like in text editor. So there are our ideas for development and, that's it. Whoops, it's supposed to be a star.