Giter Club home page Giter Club logo

elm-review-no-unsorted's Introduction

elm-review-no-unsorted

Provides elm-review rules to ensure that anything (readily) sortable in Elm code is sorted in the "proper" order.

Provided rules

Configuration

module ReviewConfig exposing (config)

import NoUnsortedCases
import NoUnsortedLetDeclarations
import NoUnsortedRecords
import NoUnsortedTopLevelDeclarations
import Review.Rule exposing (Rule)

config : List Rule
config =
    [ NoUnsortedCases.rule NoUnsortedCases.defaults
    , NoUnsortedLetDeclarations.rule
        (NoUnsortedLetDeclarations.sortLetDeclarations
            |> NoUnsortedLetDeclarations.alphabetically
        )
    , NoUnsortedRecords.rule
        (NoUnsortedRecords.defaults
            |> NoUnsortedRecords.reportAmbiguousRecordsWithoutFix
        )
    , NoUnsortedTopLevelDeclarations.rule
        (NoUnsortedTopLevelDeclarations.sortTopLevelDeclarations
            |> NoUnsortedTopLevelDeclarations.portsFirst
            |> NoUnsortedTopLevelDeclarations.exposedOrderWithPrivateLast
            |> NoUnsortedTopLevelDeclarations.alphabetically
        )
    ]

Try it out

You can try the example configuration above out by running the following command:

elm-review --template SiriusStarr/elm-review-no-unsorted/example

Changelog

  • 1.1.8 -- ๐Ÿ› NoUnsortedRecords now keeps record info from indirect dependencies. Previously, only information in direct imports was kept, due to an oversight in how elm-review works. This should lead to fewer records being unknown now and thus correctly sorted.

  • 1.1.7 -- ๐Ÿ› Fix bug in NoUnsortedRecords where record patterns could be considered ambiguous due to fields in type annotations being ignored. For instance:

    type alias FBB = { foo : Int, bar : Int, baz : Int }
    type alias BBF = { bar : Int, baz : Int, foo : Int }
    
    fooBar : { bar : Int, foo : Int } -> Int
    fooBar { bar, foo } = foo + bar

    { bar, foo } was considered ambiguous even though it can't match FBB or BBF due to the type annotation specifying that baz is absent. The fix works with extra fields and generic records as well, e.g. { r | bar : Int, extra : Int, foo : Int } also prevents ambiguity, but not { r | bar : Int, foo : Int }.

  • 1.1.6 -- ๐Ÿ› Fix bug in NoUnsortedRecords where multiple record matches were not considered identical orderings if the indices of the matching fields were different. For example, the following record update was considered ambiguous before this bug fix:

    type alias A = { a : Int, b : String, c : Bool }
    type alias B = { b : String, c : Bool }
    
    a r b c = { r | b = b, c = c }

    Since b and c had different indices in the matching records, even though the sort order was the same.

  • 1.1.5 -- ๐Ÿ“ Improve docs for NoUnsortedCases.doNotLookPastUnsortable

  • 1.1.4

    • โšก๏ธ Improve performance when dealing with ignored files (~10% in one real-world test case).
    • ๐Ÿ› Bump elm-review to v2.12.1 for upstream bugfix.
  • 1.1.3 -- Bump elm-review to v2.11.1 and mark rule as providing fixes.

  • 1.1.2 -- ๐Ÿ› Fix a bug where, when dealing with cyclical sorting conditions, some low priority edges associated with the cycle but not actually responsible for it would be disregarded instead of only those responsible. In practice, this meant that, very rarely, sortable case patterns would not be sorted at all (or would be sorted unstably) when wildcard (_) patterns lead to cyclic ordering relationships. Since the problem at the core of this is NP-hard, it is not guaranteed to be fixed but should nevertheless now occur substantially less often (if at all). Please open an issue if you encounter unstable sorting behavior or case patterns that should be able to be sorted but are not with this version.

  • 1.1.1 -- ๐Ÿš‘ Fix critical bug caused by upstream bugfix in elm-syntax. Version 7.2.9 of elm-syntax no longer incorrectly parses record field type signature ranges, so NoUnsortedRecords (which repaired the previously incorrect behavior) was producing in invalid ranges for fixes, causing them to mangle code. elm-syntax new lower bound is set to 7.2.9 and the workaround removed, fixing the issue.

  • 1.1.0

    • New Features:
      • โœจ -- Disable typechecking of unambiguous records by NoUnsortedRecords. The old default can be re-enabled with typecheckAllRecords
      • โœจ -- Add control over subrecord support for NoUnsortedRecords. Default behavior is to sort them when they appear in context (e.g. as part of their larger record) but not when they appear alone. The old behavior did this unreliably and also treated custom type argument records as always canonical; this old behavior may be re-enabled (without the unreliability) with treatCustomTypeRecordsAsCanonical. New settings for this behavior are also available with treatSubrecordsAsUnknown and treatAllSubrecordsAsCanonical.
    • Bugfixes:
      • ๐Ÿš‘ -- Fix critical bug causing control flow to sometimes be altered by NoUnsortedCases due to List.sort assuming transitivity. New sorting methodology renders such issues impossible in the future.
      • ๐Ÿ› -- Fix doc comments not moving for ports with NoUnsortedTopLevelDeclarations (possibly leading to invalid code after fixes). Doc comment support for ports was added manually, as elm-syntax does not parse them, and they now behave like doc comments for all other declarations.
      • ๐Ÿ› -- Improve handling of subrecords by NoUnsortedRecords. Previously, they were sometimes sorted and sometimes not (depending on what type information was available). (See above for new configuration options controlling this behavior.)
      • ๐Ÿ› -- Fix bad type checking by NoUnsortedRecords assigning independent type vars to the same type, e.g. assigning all Nothings to the same Maybe a value, even if they were different.
      • ๐Ÿ› -- Fix bad type checking by NoUnsortedRecords preserving type var assignment between fields (for type vars not in the known record), causing e.g. all Nothings in a record to be required to be the same type.
      • ๐Ÿ› -- Fix bad type inference of lambda functions by NoUnsortedRecords.
      • ๐Ÿ› -- Fix non-functions being considered dependencies/helpers by NoUnsortedTopLevelDeclarations. This brings actual rule behavior in line with that stated in the documentation.
    • Other Changes:
      • โšก๏ธ -- Significantly improve performance of NoUnsortedRecords (2x faster on some real-world codebases). Previously, a significant amount of unnecessary type inference and duplicated recursion was being performed due to lack of laziness.
  • 1.0.6 -- ๐Ÿ› Fix a bug causing NoUnsortedRecords to recurse infinitely in certain rare cases where a type variable was assigned to a value containing an identically-named type variable (e.g. the type variable a ended up being assigned to a value defined by the generic record { a | field : Int }).

  • 1.0.5 -- ๐Ÿš‘ Fix critical bug causing NoUnsortedRecords to rarely generate valid code that was missing fields for record updates. It is recommended that you check any record update expressions that contained comments that were fixed by this rule prior to this version, as one or more fields may have been appended to the end of a comment in sorting.

  • 1.0.4 -- Update to elm-syntax v7.2.8 to fix upstream issue with lambda ranges generating invalid code in fixes.

  • 1.0.3 -- Fix crash with --fix or --watch due to comparison of function types in ProjectContext of NoUnsortedRecords.

  • 1.0.2 -- Fix crash in handling of record type comparison.

  • 1.0.1 -- Fix crash in handling of generic records when not all fields must be present.

  • 1.0.0 -- Initial release

elm-review-no-unsorted's People

Contributors

dependabot[bot] avatar siriusstarr avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar

Forkers

pascallemerrer

elm-review-no-unsorted's Issues

Fixes suggested by NoUnsortedTopLevelDeclarations create invalid Elm code

Problem

The fixes suggested by NoUnsortedTopLevelDeclarations fail to apply.
[rkb@nixos:~/projects/tulars]$ elm-review --fix-all
-- ELM-REVIEW ERROR ------------------------------------------- app/Main.elm:1:1

(FIX FAILED) NoUnsortedTopLevelDeclarations: Top-level declarations are not
sorted.

1| module Main exposing (closeTabAt, main, pickUpFood)
   ^^^^^^

Top-level declarations were found out of order.  They should be sorted as
specified in the rule configuration.

I failed to apply the automatic fix because it resulted in invalid Elm code.

app/Main.elm  โ†‘
====o======================================================================o====
โ†“  app/View.elm


-- ELM-REVIEW ERROR ------------------------------------------- app/View.elm:1:1

(FIX FAILED) NoUnsortedTopLevelDeclarations: Top-level declarations are not
sorted.

1| module View exposing (view)
   ^^^^^^

Top-level declarations were found out of order.  They should be sorted as
specified in the rule configuration.

I failed to apply the automatic fix because it resulted in invalid Elm code.

I tried applying some fixes but they failed in ways the author(s) didn't expect.
Please let the author(s) of the following rules know:
- NoUnsortedTopLevelDeclarations

I found 2 errors in 2 files.

repro

$ git clone [email protected]:r-k-b/tulars.git

$ cd tulars

$ git checkout 64028a61954c7794b5d8fbbe05add82a8a3f6f61

$ node --version
v14.17.6

$ npm i

$ elm-review --version
2.5.5

$ elm-review --fix-all

elm-review --fix crashes on a certain NoUnsortedRecords operation

After installing NoUnsortedRecords I was able to --fix a few previous occurrences, but this one consistently fails:

"I ran into an unexpected error"
[rkb@nixos:~/projects/tularstmp]$ elm-review --fix
-- ELM-REVIEW ERROR ----------------------------------------- app/Main.elm:587:7

NoUnsortedRecords: Record fields are not sorted.

586|     in
587|     ( { agent
           ^
588|         | physics = newPhysics

Record fields were found out of order.  They should be sorted as specified in
the rule configuration.

I think I can fix this. Here is my proposal:

 588|         | physics = newPhysics
 589|         , topActionLastStartTimes = newTopActionLastStartTimes
 590|         , callingOut = newCall
 591|         , hunger = newHunger
 592|         , currentAction = topAction |> Maybe.map .name |> withDefault "none"
 593|         , currentOutcome = newOutcome
 594|         , holding = newHolding
 595|         , beggingForFood = beggingForFood
 596|         , hp = hitpointsAfterStarvation
 597|         , currentAction = topAction |> Maybe.map .name |> withDefault "none", currentOutcome = newOutcome, hunger = newHunger
 597|         , beggingForFood = beggingForFood, topActionLastStartTimes = newTopActionLastStartTimes, callingOut = newCall, holding = newHolding, hp = hitpointsAfterStarvation
 597|       }

โœ” Do you wish to apply this fix? โ€ฆ yes

-- UNEXPECTED ERROR ------------------------------------------------------------

I ran into an unexpected error. Please open an issue at the following link:
  https://github.com/jfmengels/node-elm-review/issues/new

Please include this error message and as much detail as you can provide. If you
can, please provide a setup that makes it easy to reproduce the error. That will
make it much easier to fix the issue.

Below is the error that was encountered.
--------------------------------------------------------------------------------
Error: https://github.com/elm/core/blob/1.0.0/hints/5.md
    at _Debug_crash (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:460:8)
    at _Utils_eqHelp (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:554:30)
    at _Utils_eqHelp (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:587:8)
    at _Utils_eqHelp (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:587:8)
    at _Utils_eqHelp (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:587:8)
    at _Utils_eqHelp (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:587:8)
    at _Utils_eqHelp (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:587:8)
    at _Utils_eqHelp (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:587:8)
    at _Utils_eqHelp (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:587:8)
    at _Utils_eqHelp (/home/rkb/projects/tularstmp/elm-stuff/generated-code/jfmengels/elm-review/cli/2.5.5/review-applications/3835e632b06db71195022df297a481d6.js:587:8)

The issue may be related to the use of functions within the ProjectContext. jfmengels/node-elm-review#60

repro

$ git clone [email protected]:r-k-b/tulars.git

$ cd tulars

$ git checkout 424d21546444e1642de657f02874485814e5fae8

$ node --version
v14.17.6

$ npm i

$ elm-review --version
2.5.5

$ elm-review --fix

Hit Y, then crashes like the one shown above happen. It will crash the next few times too, but on different reported problems.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.