"Backslide" scripts for incremental 0.19 upgrade

In the latest Elm Town podcast @rtfeldman and @luke coined a term “backslide”.

They’re getting their codebase ready for 0.19 upgrade, are getting rid of stuff like Debug.crash, (,) etc., and don’t want for it to appear again in the codebase.

They’ve hinted at a “backslide script” or “backslide.js”, which makes sure they don’t, well, backslide into usage of these patterns.

Richard, Luke, or anybody else that does this, I’d like you to share at least the outline, if not the whole script, of how you do this. And do you run it as a git precommit hook, or in CI?

All and any details would be most welcome, because we’re in the same situation. :slight_smile: Have eradicated some patterns, are waiting for some packages to upgrade, and in the meantime would like to keep the 0.18 codebase free of 0.19-problematic patterns.

2 Likes

Here you go!

The backsliding scripts will probably continue to evolve as we eliminate more stuff but this is how it looks today.

We run the shell script in an early stage of CI, so in reality there’s a bunch of CI-related stuff in the bash script to correctly notify the build of failures. The infixes python script doesn’t actually run because it is searching for infix operators that came from packages. We uninstalled the packages, so it’s no longer possible to use them anyway.

If anything doesn’t appear here that means we haven’t gotten around to removing it from the codebase yet :smiley:

7 Likes

Today I encountered an issue where backsliding also provided a solution (Thank you, @folkertdev and @norpan!)

module Future.String exposing (toInt)

{-| Resolves a bug in Elm 0.18 that is fixed in 0.19 with parsing a string to integer.

Specifically, the 0.18 version of `String.toInt` breaks on the input "-", which is improperly converted to `Ok NaN`.

-}


toInt : String -> Result String Int
toInt string =
    if string == "-" then
        Err "Cannot convert \"-\" to an integer!"

    else
        String.toInt string

Note that my module naming is the other way around, because:

  • It means there’s only one weird folder in my project rather than one per module in elm/core.
  • It makes it easier to maybe export this stuff as a 0.18 package at some point.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.