 Hi again, hi everyone. So my name is Matthew and I've been working with Elm for quite some time now. Creating packages in Elm is something that everyone should be interested in because it's how we grow the community with the number of packages. It's not the only way but it helps. So I will talk about that and it's not going to be me talking alone. So if you have any questions at any time, stop me and ask your question just straight. Don't wait for me to slide or to slide or I hope it will be interactive. So yes, so we go through how current package system work, then some of the issues with the way it works right now. How we design a package, when should we create one, why should we not. And actual practice about publishing. I will need a volunteer for a demo will not go through the end of the story, but we'll just try to go through and at some point we just not publish it. So this volunteer will work on the creation of a package and then I will show the update of a package with one package that need updating. So that's it. Let's start. So first the Elm package repository. So who won here has already seen this website. Okay, so I guess the others have not been using Elm yet. So this is like your home page when you are doing Elm development. This is a very simple page. You have a search engine here, quite basic. Basically, you can just search for things that are in the name of the package or the user name of the creator of the package or the description of the package and that's all. You have some fancy search engine for looking for types of functions, but I'm not sure it's working very well because sometimes I try to use it. Yeah, I don't know. So you have on the right side interesting resources like basic guide of how to use package and design guideline for API for documentation, etc. And just below that you have links to the most common packages in Elm. So whenever you have a question about how this function works or how this other function works, you should find it here. Usually it's in core if it's core Elm function or whatever thing you need. How is the API design guideline? Yeah, it's okay. It's quite small. I have the link later so we can go there if you want at some point. It's just generic guideline. It's not very specific. It's just detailing you what you should do, what you should not do extra. But we go there. So the first thing you have to know about packages is how to describe a package. So in NPM you have the package.json file that describes your node package. And in Elm you have the Elm package.json file that soon will be a bit different. Hello. So it's quite simple. You describe the version. So this is what this file looks like when you create a new project. You don't have added any other dependency or anything. It's basic. Yeah, it's just how it looks like at the beginning. So version, summary where you put the summary of your package, where your package live. So on GitHub we'll tell a bit more about that later. The license of your package. So by default I think it's BSD3 for everything. You can choose something different, of course. The advantage of this license is that it's very permissive. So you can reuse those packages in any open source project or private project if you want to re-license it. Or do anything that is cooperative with it. It's like MIT license, no? Yeah, it's roughly like MIT. It's a little less permissive than MIT, but it's roughly like MIT. And at the other end of the spectrum you have the GPL license, which is really co-pilested everything. You have one GPL file, your whole project must be GPL. And in between you have the MPL license, Montila public license, which is more permissive. You can reuse MPL file in other projects, which are not MPL, but the file still needs to stay MPL. So it's more flexible and you keep the fact that the one thing you wrote open source is always distributed as open source. So then you have the folders that contains your modules. Initially it's just the current directory. You have the exposed modules in those folders because you don't have to expose everything. You can just expose a few different modules of your package. And the dependency of your package depends on it. So we'll see how it works a little bit later, but basically you say the name of the package and then the version of the package. So it will be always something like that. We'll explain it later. And finally the version of Elm you are using, because of course Elm is very opinionated and not like Python for example. When the main version changes, everyone has to change to the main version. Otherwise the ecosystem is not as good as it should be. So you always have to specify the version you are using so that other people know and the system knows if it's compatible. So how do we install a package? It's simple actually. If you have Elm installed on your computer, the best way to install a package is just find the package on the repository, the website repository. And then you have the name of the author, the version of the name of the package, and it's just an package installed on this thing. So this, it will change the JSON file by adding a new dependency here and downloading the source of the files and put them in some special directory. So yeah, quite simple. There is another way to do it. So instead of just using Elm package install, which will put a new line in the dependency here, you can just put manually the new line in the dependency and then call Elm package install without anything. So if you have a lot of package to install at once, you can just add all the names here in this file and then do Elm package install and it will install everything. You don't have to use Elm package install, the first one, Elm package install, the second one. Actually, I don't know if you can do Elm package install and then multiple packages. Does anyone know? No. If you don't do minus Y, it always has three things to install. Yeah, yeah. This way you have to do it once. Using a package, quite straightforward. If you have a package, I will take the example of this package, mouse. This is the GitHub repository and the package is available in here. Mouse events. Oh shit. I'm trapped in my own game. So here, for example, there is one module in this package. So this thing reflects the rhythm of the package and then the modules are here. So there is a mouse module which has a few different types and functions. So if you want to use, for example, the mouse module inside the Elm event package, nothing complicated. You just, in your file, like main.elm, you just import mouse. If you have installed it before with this or this, it will just work. So just import the modules of the package you have already installed and it's okay. Removing a package. What happens if you have another module that's exposing the same variable mouse? Yeah, same module name. It doesn't work. Yeah, so there are very rare issues like this one, but there exists between different projects. I think there is even one between the style elements and the CSS. But what you should do usually is try to namespace your module, like, for example. So when you are creating a package, you are uploading it from this package site, right? Does it keep throwing exception and telling you that, hey, is somebody ever going to give you the name now? No, no, because multiple people can have the same module names. If it's not in the same context, they should never be used at the same time. So Elm doesn't prevent you from publishing a package with modules that have the same name than other packages. So you can. But what you should do if your use case is not really specific is namespace your modules. Like, for example, this is a package called OpenSolid Geometry. It's to do some geometric stuff. And here, all the package names are namespaced with OpenSolid. So that if you want to use these packages, you cannot have any conflicts with other, I don't know, other libraries that will have the vector 3D module or something like that. Which can be quite common if you compose different linear algebra library or something like that. So if there are two modules with the same name and you have unfortunately installed them, is there a way on code that you can alias the import? You can alias the import. But after importing, you can use import something as something else. But the import something will not work if you do it two times. It doesn't know which one it is. So you can alias from module name to package, right? Yeah. And alias the name. So in that situation? Yeah, you can do anything. Yeah, it's good. But I mean, people try, because if it's two projects that are likely to be used together, usually the authors know that they are likely to be used together. So they try not to use the same names, module names. But yeah, it can happen. So removing a package. I don't think there is a comment for removing a package. So what you have to do is just remove the line and packages on file. And then you can try to remove only the module things that are inside these folders that are related to this package. But really, usually, you will just remove all these directory, which is where Elm puts everything it needs, the sources, the compilation and everything. So you just remove this one and you re-download the packages and you recompile the packages. I mean, it will re-download it automatically, but it will just take longer time to recompile, but it's safer to do it this way. So the versioning of the packages. When you specify a package, you specify a version like this one. And what it means is that the meaning actually is really precise. The versions of package are semantic and forced, meaning it's just not semantic that you choose the semantic. It's a semantic that is specified and that is enforced by the Elm compiler. And what is enforced is that you have three parts in the version, a major, a minor and a patch. So a major change means that there is a breaking change in the code. So for example, one function doesn't have the same signature as before, or one function was removed from a module, or one module was removed, or one type has changed. Hello. You don't change the signature of the function, but you change the function itself. So you mean the implementation inside? Yes, the implementation. So it's just a patch. So internal? It's just a patch. Even though it's a breaking change? It cannot be a breaking change. If the signature doesn't change. The behavior of the function? The behavior? Yeah. Yeah. Of course. You have a function add and instead of adding, you just multiply and change the... Yeah, of course. Of course. But people won't do that. Yeah, so it's just the... It's the behavior, yeah. So what it means is that you will not have a compilation error or runtime error, because you never get a runtime error, but you will not get a language error with a patch or a minor issue. But of course, you can get behavioral logical error. Yeah. You cannot prevent that. Or maybe we can in a few years, I don't know. So major, so something break. So that's why when you specify a dependency of a version, if you know it worked with this one, you know it will work until the next major break. So you won't have any issue with this. Minor is the second. It means that it is a non-breaking change, but something still important, like a new functionality that was not available before, like you have a new module or you have a new function or a new type declared somewhere. So usually it's new stuff. And then you have the patch modifications. So these are just transparent for the code, for the compilation aspect of the code, meaning the documentation change or an internal implementation change, but it won't change anything for the users of the package. Sorry. Yeah. You mentioned that Elm actually enforced this version name. Yeah. How does it enforce? So when you try to publish for the first time a package, it must be 1.0. 0. And then any time you want to update a package, there is a command which is Elm package bump and it chooses the new version. It's not you who chooses it. It chooses the new version and it modifies automatically this. Do you know how it works? Yeah. It analyzes the type signatures of all your codes and it basically has rules like these ones. So if there are only new stuff, it's just non-breaking change. If there are stuff that are changed from the last time you publish the package, it's breaking change and like that. And it compares to the current version on the package? To the last one that was published. And with the next one that you are going to publish, so the one that is in your current workspace state of your Git project. Because everything is versioned with Git. Because you have to put it on GitHub. Any other question about this? No? Okay. So yeah. The good thing with enforcing versioning is that you never have a breaking issue because some package just thought that they were doing a minor change but actually it changed something major for someone else. Okay. So a few drawbacks of the system, the packaging system. First, it's hosted GitHub. So this is something that Evan said he is also a priority. I guess not really high priority but they want to have their independence from GitHub at some point, at least for the version that has already been published. But right now it's not the case. So you don't control GitHub. So anything happened to GitHub, and doesn't exist anymore. So behind a corporate VPN which blocks access to GitHub? Really? Yeah. Yeah. So for example. Yeah. So yeah. Just how it works. So when you use the mPackage command, you exchange information with GitHub and with the mPackage website also that has a few things that are stored inside there. But every data, the source and everything is pulled from GitHub. So for example, I had an issue one time where I wanted to use a package that was published. All the documentation, everything was on mPackage. And when I tried to use it, I had an issue with GitHub. So I was thinking that my connection was broken. It was just that I thought the package removed the package from GitHub. So you couldn't download it anymore. So every package that depending on this one could not work anymore. Yeah. So the entry is still on the mPackage website with the actual package itself? Yeah. When you publish, it loads a few things like documentation like the descriptions of the mPackage JSON. But the sources are not fetched. So only some descriptions or I think it's fetched like the type signatures of stuff. But I'm not sure. When you're doing a health package or like under the hood, how does it bounce to GitHub? Does it use SSH to clone the report trees or just HTTP grab the JSON files? I think it's HTTP, not SSH, because you don't have to set up any SSH to use it. But yeah, because if Elm wanted to use it with their own token or stuff like that, it will, I mean, I'm not sure they could use it every time or for every user, every Elm user. So I think it uses their HTTPS. But it's not an issue for public packages because you can always access them with HTTPS. So another big issue with the package system is that for now, for 0.18, it will change in 0.19, all things are installed locally in your project folder. So meaning you want to create a new project that just depends on the core and the HTML thing that you have already installed in five of your other projects. You cannot do it or you have to manually hack it by copying and pasting things by hand. But the normal way using Elm install something, it will have to pull again the things from GitHub and to put it inside your Elm stuff directory. So inside this thing you have different things. You have the sources of the different package you are using. You have the build artifacts that are already being built so that you don't have to rebuild everything each time you compile. And you have a file that gives you the exact dependencies so that you could use this one to reset up the project for something else. I think it's useful for analysis thing and to know exactly what is installed in case you have a minor change that changed the behavior, for example. You said right now it's the case, so are they going to change it in version 19? Like is it going to be global installation? With Evan you cannot say 100% but it's been said in different medium of discussions that it's going to change. Like they want to have in your home space, in your home directory like a .elm folder or something similar in which every package you pull will be installed in this hidden folder, hidden directory. So that each time you reuse a package that you have already downloaded, already compiled it, don't have to do anything, it's just compiled and downloaded in your home folder somewhere and you just pull it and it works. I think it's going to be this way, I'm not sure. Another issues that we didn't discuss previously with the packaging system of Elm is that to make sure that you have the guarantees of Elm, meaning no runtime errors and everything works when it compiles, you cannot have JavaScripts in your packages. So it's Elm 100% or it cannot go to the package repository. So meaning if you want to use a JavaScript package which is in MPM you have to rewrite it in Elm or to use ports. So if you know what port is, there are the means of discussing between JavaScript and Elm to make an interface of the different APIs. So it's growing. Like if you go to this web post and read it, the guy who said that there are currently this amount of packages is just scrolling and just one JavaScript command to count the number of things that are on the websites. And he says that six months ago there were like 200 or 300 packages and now it's almost 800, so it's growing. So even if sometimes people think that Elm is stale or stealing, it's not. It's just that the master branches of the development are still because they are working on the dev things and they do major updates really slowly that it's going to be a year now since 018 has been out. So it's really stable actually, even if it's not a stable version. So soon we will have 019. I think maybe a month or two, something like that. I have no idea. Did you feel that there was some really missing package? I know there's like a few packages, but everything that I was looking for I always kind of found something. I've not been using a lot of web development packages, but I know there are web API that are missing that are important like using database. You can find some custom GitHub repository where some guy has it's not on the end package website. It's like your custom package that you installed with another installer, but you can always make it work. And so I found that most of the time when you need something at least one person has found like a solution. Yeah, it's not always easy to find that. Yeah, that's the one. I think that one is more permissive like it allows package authors to make it code. Yeah. And GitHub Insta? Yeah. If you want like some home code package, that's the one you use. Yeah. You can do that. I'm not sure you should, but sometimes you can. Yeah, I don't know what's wrong with it. It's just like they use native code. From the individual personal point of view, there is nothing wrong with it. From the community point of view, it can encourage people using JavaScript in Elm. And it's not the way that Elm wants to be developed because in the end right now JavaScript is just a compiling platform. So if you are using JavaScript in a package, it means that you are committing to JavaScript. And at some point, for example, if everything is going to be compiled to WebAssembly or whatever language, your code is not working anymore. Yeah, just in the meanwhile until the 19th, the library is going to get a little bigger. Yeah, of course. And we will have like children before it's compiling to something else. So yeah, we have time. Is it possible theoretically that it will compile to something else? Yeah, I think at some point it will compile to WebAssembly. But the WebAssembly ecosystem is not mature enough yet because it doesn't have a garbage collector to languages that don't manage their memory themselves. But yeah. I think it's possible because there's no competing language of JavaScript and JavaScript are currently compiled to JavaScript and I think they have another compiled package. Okay. Yeah, C++ and others, but it's a bit buggy I get, I think. Yeah, I agree. I think the core message is that as soon as you introduce direct bindings to JavaScript, you also give up the guarantee of no runtime errors. So you deliver that which you live within your JavaScript, right? Yeah. And you're probably fine. But seeing whether the community likes to see whether we can solve the problem without going to the major part, right? And a lot of things have actually shown up to be very nicely solved or do things, for example. Yeah. Even if there are sometimes better abstractions. So I think that's sort of the reason there is... It's also, I think, trying to encourage people to write Elm, to develop Elm code that do things that are already done in older languages, but better. So, yeah. So you just talk about it. What do you... You cannot... With the Elm package official system, you cannot install private repository or repository that lives somewhere else on GitHub, on that on GitHub, or on your machine. So to do that, you have two tools. You have Elm GitHub install that you mentioned before. And you have another one, Elm Groove, that basically replaces Elm package manager. So it can install local packages and GitHub native and effects manager packages. But, yeah, as we said before, you should use it only if you know what you are doing and if you don't want to regret it later. I guess the best use case would be if you're building a large number of modules in German, right? Yeah. So a few designing steps for your package. So when should you create a package? Or when should you not? So you have general guidelines about creation of a package. So the guidelines are there. So it goes through this point. So when should you create a package? So when you have something special you want to take care of, try not to do something too generic, too general. Yeah, that's the no Haskell point because sometimes they want to do something too generic. Write good documentations. This one is really interesting. The data structure should be the last argument. It means that when you design your API, if you put the data structure or the main data of a function as the last argument, you can reuse it in the function that is after in your flow of computation. And you can use the pipe syntax in Elm. I don't know if you know about it. If you don't know just, it's explained in the guide. But it's really nice to make a flow of computations and see how things evolve little by little. So it's a really good advice. And then a few things about namings. Don't use three-liter namings. Don't use TLA, three-liter abbreviations. Avoid infix operator. So infix operator without a name because it's not usable if you want to research them on the package and the functions. If you want to know what it's doing, it's better to research something with a name, with letters. So yeah, these are basically the main guidelines. And so then, once you know about that, when you think of creating a package, you should ask yourself at least these questions. So does the feature you want already exist somewhere? So you have to look on the package, the Elm package website, of course, also on GitHub, sometimes packages are not published on GitHub but someone has already done it. And if it's not available, is it just a small extension of something that already exists or not? If it's a small extension of something that already exists, the better way to do it is just contacting the person that is doing this repository. You can contact them usually through GitHub with issues or just Elm Slack, and discuss. It's the best way to grow the community and to have the things. Maybe sometimes you didn't even think of something and the creator of the package know the reason why it didn't do the thing you want to do and it gives you a better insight of what you want to achieve in the end. So then, are you sure you need this? It's not just something you need one time in your project. Was this something you have been using repeatedly and you think a package would be useful? And is this something that is implementable only with Elm, no JavaScript, because otherwise you cannot create a package, an Elm package, and is your API not too generic but not too specific either like just in the right balance in the middle. So once you decide you create a package, what are the things you need to do? Okay, so first we say contact authors of similar packages and ask them if they are willing or if you can with a pull request implement your new features. If they are not, verify that the package you want to create has a unique name because it's a mistake that some people did including me creating a package name that has the same name of someone else and it's not a good idea because then when you want to reference it, you have to reference it with the full name and sometimes people look for it and they don't know which one they want to choose because they are the same name, etc. So try to be specific about what you are doing in your package with a specific name. Then add license on readme, so it's basic advice but you have to do it. If you have images that you want to add in your readme, images for example that are inside the repository, you can display them. But when they are published on the mPackage website, they will not be visible because the mPackage website is not GitHub so they don't have access to things that are inside the repository. So if you want to add images, visuals in your package in the readme, use something else with absolute reference of the image. So what good advice for this is that on GitHub for example, every user on GitHub can create your username.github.io repository and inside this repository everything that is inside this repository will be accessible through a statically accessible from GitHub. So you can put an image somewhere inside there and this link will work and will display the image even in the package manager. So it's better if you want people to see your images in the package manager, not only on GitHub. So you have guidelines for the documentation also and you have a way to preview documentation. So this is really useful and we'll use it I guess in a few minutes. And then also try to do tests and provide examples for your package otherwise people are not going to use it and people are not going to help you with your package and implementing stuff or whatever. Okay, so actual publishing. So first package release, I will need a volunteer who wants to try to do it. So who has never published any package here? So who volunteer? Come on, come on. So I've created a folder here like Meetup. There is already some stuff inside, I'm going to remove this. I think Star will work. Oh, yes, yes, yes, yes, yes, yes. Okay, so there is .git folder left. It's okay. So, yeah. So you type here and I look here. Yeah, because it's not mirrored. So yeah, so first we will initialize the repository. So the git repository I've already initialized it so you don't have to initialize it. It's a good idea to put a gitignore file in all your repository because you don't want to put something online that shouldn't be online. So there is a website that's called gitignore.io that's really useful. You just put the different things you are using like OS6, Windows, Elm, whatever. And then it gives you a file. So usually I do just this, I get the file and I put it in a gitignore file. So copy and paste that? Yeah, but it's okay, it's already done I think. Okay. Oh no, it's not done. Oh no, it's not done. So yeah, you can do this if you want. Oh yeah, no, it's not working. Now whatever, forget the gitignore file. So we'll start by initializing the package. So even, yeah, you can do Elm make even in an empty directory so it will create a few things. The keyboard is very difficult. It's a French keyboard. Yeah, I have a Japanese keyboard. I have a Japanese keyboard? Yeah, you have a Japanese keyboard. So the Elm, yeah, Elm is asking you if you want to install a few things. So it should not do this. It's just because the window is a bit small, but yeah. So it has compiled 37 modules. Yeah, we thought we had only three modules. But yeah, it's because there are modules that depend on other modules that are not public modules because there are multiple modules in each package. So that's why. But once we have done it, we don't have to compile any more of those ones. So it will be faster. Okay. Do you want to create what project do you have in mind? What kind of? Or anyone? Anyone want to project something, to create something? Like, I don't know. What? He said pad left. Pad left? What was it? Pad left, like string padding or like if you have some string, you pad it left with some zeros or some spaces. A package to pad left? Yeah, whatever. You can create a pad left if you want. So I just create the source? Yeah. Usually it's better to put everything in the folder. So create source folder. And then create your module. So, yeah, it's, yeah. All right. Do you use VMore? No, but I guess I will learn today. No, but then it's, I have also Atom, I think. Yeah, I use VS Code, but I guess Atom is fine. Yeah, yeah. Use Atom maybe. But I need to make a new file. Yeah, usually for me I have E, I type E and it opens later. Yeah. I don't know, type whatever you want. You can use, you can use an Atom. Yeah, yeah, I think so, I think so. But I have to create a file first. So you have to find a name, that's all. Atom and then. Pad left. Yeah, I think it's a good name. But if I just type Atom before you will create the file as well? I think so. Are there Atom experts here? Yeah. Touch it first. No, it's not, it's not. Oh, it's not, oh yeah. It's not installed. Maybe I'll install it. After last I'll meet that guy. So, whatever you want. CD into source, no? Yeah, yeah, yeah. Use what you want. If you don't have VS Code maybe. Oh, maybe JEDIT will be easier. I can use a... Okay, okay, okay. There's the weird, like I have to keep my hand on VS. No, no, no, no. We'll just enter in edit mode and it will be okay. So we say pad left. No, pad left. Oh, that's it. Oh, shit. Yep. Okay. So, maybe we can put this thing on the right so that we can read the error messages there. Yeah. Do I do that? You click here and you move this in right. You got it? Yeah. No, yeah, click. Click. Oh, no, yeah, it doesn't work. Sorry. Yeah, yeah, yeah. It's only... Sorry. So insert with E. Yeah. I, sorry. And then, yeah, you can write. So, you know a bit of... Elm, yeah, yeah. Yeah, but I never wrote a model from scratch. It's like main module or something like that. So you start by module, little m, little m. Okay. And then the name of the module. So it's a pad left with, yeah, upper, how? Expose main or something like that. Exposing. And then, yeah. Exposing and then inside brackets, two points. So we will expose everything for now. Yeah. Okay. Okay. And it's like main, like depending if you were doing like a beginner program or whatever program you put the main... No, because we're not going to do a program, just a package. Yeah. So we don't need any main. Okay. So we can just start with the function, one function we want to expose. Okay. So I think we can call the first function like pad left or something like that. With little p. Yeah. So this will be something, maybe a string, right? So the first thing is the name of the function. Okay. Yeah. Oh, yeah, yeah, yeah. Name of the function. Two points, right? Yeah. A string. So this is the type signature. So it takes a strings and returns a string. And it's an arrow like that. Yeah, the arrow is somewhere here. Yeah. It's okay. How do you view the content of the community? Sorry? How do you view the content of the community? I can view here. Like I have the modification here, but then I can also just... If it's just a small modification. Okay. I have the modification there, but... Is it okay? Yeah. Okay. We're live because we are missing some sound for the video. So where was I? So it's committed. Then you have to tag. So one thing that is a bit redundant is that you have the version in the package file, but you have to tag it for Git also so that the Elm package website knows which source it has to retrieve. So we will tag it. It's version 1.1.1. Okay. And then we push everything, including the tags. If we didn't push the tags, it will not work. It will say to us that it's not working. So in the end, you just use Elm package publish. It verifies that everything is in order. So... And there it is. Live. It should be actually. So we have this that is updated. So now I can click on the button if internet works. Yep. And it's 1.1.1. So quite easy. Just few commits, change files, bump automatically. You try to run your tests and everything so that it works, that you don't push versions that don't work. And that's all. Thanks. Verify that the tag version and the version and the package file match. A mess. If they don't match, it's a mess. But I don't know what mess it is. I know that at some point, I tagged something... What is really, really annoying is when you think it's going to be right. So you tag your code and you push it on GitHub. And then you publish and something is wrong, either in the publishing process or you made a mistake in your code or something like that. When you do this and if the publish is wrong, for example, and you have to redo modification, you have to redo bump and it will bump to another version. It's a bit mess. So if something like this happens, the best thing I think is just to undo the commit, keep it as stash and redo it correctly. But un-tag and re-tag it correctly. You can remove the tag on GitHub. There is a command, but it's not removed automatically if you remove it locally. So you have to manually remove it and change it on GitHub. But in practice, I don't know exactly what happened if you do this kind of thing. Do you know some, Peter? I think you have to force push if you have a tag if it is already tagged in one thing. Yeah. I'm not sure. I mean, tags are quite sort of new. I thought you just need to tag it in the new version. If it's the wrong tag? Too bad, yeah. Maybe the publishing will not work. Because now if it's a wrong tag, M-Package will not find the tag that is corresponding to the version. So it will not be able to download the code. So I think the publishing will not work. Because the tag, the P-Sharp... Yeah, yeah. Yeah. So I think it will not work. So what is going to change soon? How soon we don't know? There is a roadmap about the ARM language. It's been written since April and it has not changed since yet. So it described a few things that Evan wants to work on including what is going to main evolution for the next version. So the next version is specified for single-page application. So basically how we improve single-page application for ARM using things like server-side rendering for the first initial answer so that you can have better referencing from Google, Yahoo, and whatever. It's going to be... Which backend? No, but there are some jobs, I think. Probably... The current... We don't know. No, we don't know, but I think it will just generate HTML and CSS that you can use. Yeah, maybe after you just have to manage your own server answers, I don't know. I have no idea. But yeah, I guess the backend will be node. It's already working with... Yeah, it can be anything. It must be that it will generate HTML and CSS because if you generate... No, but I mean what people usually use on backend are with conjunction with Elm. I think it should not be confused with actual server-side rendering. Yeah, yeah. On a node page that does Elm server-side rendering. I think it's this... If anybody saw the article lately where they pulled out React.js from the first page on an ARCAM member where there was a bit of a fix. Yeah, it's... The whole point would be you want to serve something quick and then you can load all the heavy JavaScript and I think that's the target for that one. Yeah, it's not intended to compile everything or to run on the server. It's just for the first page and to load quickly. So they improved a lot of trimming of the unused code. So currently when you compile your code to JavaScript every module that is needed is compiled including the JavaScript code. When you Gzip everything it's still already pretty small smaller than others framework but it's going to be... From Evan's word it's going to be like a massacre. It's going to be far smaller than what other competitors do for the assets you are serving. Yeah, and basically it will improve the way you can split your different part of the code doing multiple pages in different modules that you don't have to load all the pages on the first page and everything like that. But what it means for the package specifically is that be careful that what I'm saying is not official. So things are going to change and there is going to be a difference between what is a package and what is a project. So right now there is the same Elm package that Gizen for things that are supposed to be published in packages and things that are supposed to be just personal projects or just web pages and whatever. So there is going to be a difference. So in the new Elm.Gizen file there is going to be a type field which specifies if it's a package or not a package and then a few different things. Now you don't have the link to the GitHub repository. So I don't know if it means that it still has to be GitHub and it will figure out the link with only the name of the repository or if there is going to be some other mechanism. I hope but we don't know. And another slight difference is that there will be a difference between dependencies and test dependencies so that you don't have to download everything if you are just using something and not testing it. And yep, I think that's all. Any other questions that you didn't have yet? Why did you make your own mouse event instead of trying to just get it upstream? The one that is already given? Yeah, that's the one that you were using. Instead of using the mouse events from Elm? Yeah, and then just trying to get whatever you wanted to do to get those changes upstream. That was not something that wasn't possible. Upstream? What do you mean upstream? As in trying to send pull requests to the Elm project and all that you get. Because you cannot send pull requests to Evan. He will never accept. He wants to do things simple and what I needed for my mouse events are the positions of the mouse events and they are not provided in the HTML module. The only thing that is provided is the event. So the event and the target because you put your event attribute on the target when you create your HTML in Elm. So what you mean is that if I follow my guidelines I should have asked Evan if he was willing to. Yeah, it's not the only mistake I did with this one because there was also another module called Elm mouse events. Same name. Doing something different? Doing something a little bit different, yes. So it's not the same functionality but I should have asked him if he wanted to implement it my way. But it was just after another project I did. I did a package on debouncing and throttling. For this project I went to ask all the other creators of packages similar and most of them didn't answer. I get really nice answers from some of them but when I try to implement things, the first thing I did is using Formats and Formats and it was deal breaker. They were not using deal format so they asked me just modify what you want and don't format everything. So I ended up doing my own repository but yes, it's a good remark. I think for Evan, for my defense, I could have asked him but it would not have changed anything. For all the projects, like the other one I showed you before, the open solid which is doing geometry things, I participated in this project and I made pull requests and issues and discussed with him to implement a few things that I needed so this was better than just to implement myself everything. But for this one, yes, I didn't. So it was a bad choice. On this Elm format, I saw that Elm itself could not do Elm format. I think it's just legacy or maybe he needs some special things but he's encouraging... That could have been a solid version. Yes, but Evan and Richard are advising everyone to use Elm format. I don't think so. Yeah, probably not, you're right. I think we'll see it as we go forward. Maybe not. Because now you're talking about the Elm code. Yes. What's strange to me is that the style guide that is embraced by the Elm code base itself is not the one that is embraced by Elm format. Yeah. Different life cycles, right? Yeah, it's probably that because Elm format is quite new. So I guess Evan didn't want to reformat everything. Reformat all his code base waiting for the next big release which is going to happen soon. I don't know how soon, but yeah. I think that's the main reason why. I think we'll see. Just like Elm tests, the mic will be in close relationship. Yeah, and they are working in close relationship since, for example, the documentation, the ad docs and everything that you add in your package documentation. These things are both formatting and important for the Elm compiler. So they are working together to say how we should format it and how it should appear and etc. So I think it's going to be used in the next release. We can check. We can check. So core... Build failing. Do you remember one that was not following the guideline or just... I pick a list. Okay, so this one is not following clearly because, for example, there is two space here. It should be four with format and it should be only one line per item. So let's see. Nope. I think this is also... If you follow the discussions Evan works in bigger steps, right? This is a good example. There is an ongoing process in which he sometimes evolves other people in, which is around how the module documentation should work. So he's not too concerned right now about the little thing. He's more concerned about what's the next fix for module documentation. So we make it easier for people to publish libraries. We most likely change small things around what is going to be in format for module, for example, which will then infect pages in L format. So there are just things that bound together and he's quite aware of this. Instead of just publishing his changes and then helping everybody else catch his own graduation. Okay. I know that L tests have dependencies and a lot of third-party modules. Do you know if that's part of... Whatever goes into something critical like L tests, is that going to be moving in as part of the L community instead of forward? I don't know. I have no idea, no. I know that Evan has publishers... I mean, it goes back and forth there with this initiative around 4L community. There are some packages that were abandoned, quite central packages and the L community rose to the occasion and became sort of playful. Evan usually mentioned things like he prefers packages to be published under people's own initials. Because he knows that Matthias, for example, always duplicates other people's code. Or somebody else who provides him for himself. So it's also a way of distinguishing where does it come from? Where does it become a general bucket of the community that's harder to tell the quality level? That's just this argument. I don't know that it's good or bad, but that's as important as... That's also why some of the code packages have been put out and then put in for his own, that's for example. Because it's not that they are abandoned or anything like that. They represent the code, right? I think it's... Actually it's not that much dependency. That many dependencies. It's just functionality that I'm not in core yet and that should not be in core, I guess. So... Okay. So I think we mixed a bit together the... No, I think it was good. Thank you very much for doing this long presentation. Just arrived from the other side of the globe. So... Thank you very much.