“0.19.0-bugfix6”
This makes it essentially impossible to go from the NPM page and find the actual source of the package you’re downloading. Doesn’t seem like a great trust building practice for open source software.
The npm package uses binwrap to download and install binaries built from elm/compiler. The binaries are built elsewhere; you can’t audit the source of where they came from regardless.
Honestly, if you have any trust concerns at all about the npm installer, the smart move is not to use it. The binaries are available from elm-lang.org/installers, or if you have trust concerns with those, you can always build them from source.
1 Like
When I upgrade a dependency on npm I do like to look at the changelog and also the git commit history. There is a pull request (https://github.com/elm/compiler/pull/1884) and once that lands npm and github will be in agreement.
However, currently the commits in the latest version on npm cannot be found in the github repository. Possibly, the release of this module should have been delayed until the pull request is merged?
That link is dead. I think this is the page you mean: Installation · An Introduction to Elm
1 Like
It would also be helpful to know this information when deciding which commit hash to use in source-based distros – e.g. the nixpkgs expression for building Elm. We’d love to stay up-to-date, but it’s not always clear what kind of testing the commits at the tip of master have undergone! 
(cc @domenkozar.)
Maybe this might possibly stay open a while longer in the vague hope of some more information or a resolution.
2 Likes
This is making me concerned too.
I know about “batching” approach that Evan is advocating in his “Code is the easy part” and from experience we can all see that it leads to very nice results.
The reason it makes me concerned is that (as a Haskell hobbyist) I’d like to do some hacking on the compiler and use bits and pieces from the codebase to explore some tooling ideas.
And since elm compiler is not released as a library on Hackage (I assume it’s because Evan doesn’t want people to depend on elm as a library, so that he has freedom to do changes)
I have to rely on stack and depending on specific commits in the elm/compiler repo.
Please don’t take me wrong. I really like Elm.
In fact I’ll be switching to a new job next month, where I’ll be programming Elm full time.
I don’t want to start another flame like “elm development is not being transparent”.
Instead I’d just like to kindly ask people from the core team to shed some light about what’s been happening recently and why we can’t see any commits landing in (any branches) of the elm/compiler repo.
The compiler doesn’t have any JavaScript components, and the npm installer is just for convenience. Any minor updates to it are just to make sure that it works correctly and doesn’t cause npm audit to report vulnerabilities. The “bugfix” identifier refers to bugs with installers. All updates to the compiler with any notable impact will be accompanied by an announcement on the blog. In the future we’ll do better to make sure that the repo reflects the latest npm version, but please be assured that those commits will be extremely uninteresting.
I’d just like to kindly ask people from the core team to shed some light about what’s been happening recently and why we can’t see any commits landing in (any branches) of the elm/compiler repo.
Just a reminder that time and energy spent explaining things that are halfway finished is time and energy not spent actually finishing them, and the final outcome of a project will likely be quite different than how things look in earlier stages so it’s not actually useful information anyway.
Everyone is working hard on stuff and consulting directly with community members on relevant issues. If there are no commits in the compiler that just means there’s no code being written for the compiler. There are a lot of things to do other than writing code for the compiler so new commits is not really a good measure of productivity or a good window into current work.
I hope as a community we can continue to grow in our understanding of what it means to develop a language beyond writing code and pushing it to elm/compiler.
5 Likes
Thank you Luke for the nice explanation and for dispelling my concerns