@@ -626,19 +626,19 @@ noteForPortsInPackage =
626
626
[ D. toSimpleNote $
627
627
" One of the major goals of the package ecosystem is to be completely written\
628
628
\ in Elm. This means when you install an Elm package, you can be sure you are safe\
629
- \ from security issues (like code that runs side-effects on install) and that you\
630
- \ are not going to get any runtime exceptions coming from your new dependency.\
631
- \ This design also sets the Elm ecosystem up well to target other platforms (like\
632
- \ mobile phones, WebAssembly, etc.) since no community code explicitly depends on\
633
- \ JavaScript even existing."
629
+ \ from security issues on install and that you are not going to get any runtime\
630
+ \ exceptions coming from your new dependency. This design also sets the ecosystem\
631
+ \ up to target other platforms more easily (like mobile phones, WebAssembly, etc.)\
632
+ \ since no community code explicitly depends on JavaScript even existing."
634
633
, D. reflow $
635
634
" Given that overall goal, allowing ports in packages would lead to some pretty\
636
635
\ surprising behavior. If ports were allowed in packages, you could install a\
637
636
\ package but not realize that it brings in an indirect dependency that defines a\
638
637
\ port. Now you have a program that does not work and the fix is to realize that\
639
- \ some JavaScript needs to be added. That would be extremely frustrating! So why\
640
- \ not allow the package author to include the necessary JS code as well? Now we\
641
- \ are back in conflict with our goals for the ecosystem overall."
638
+ \ some JavaScript needs to be added for a dependency you did not even know about.\
639
+ \ That would be extremely frustrating! \" So why not allow the package author to\
640
+ \ include the necessary JS code as well?\" Now we are back in conflict with our\
641
+ \ overall goal to keep all community packages free from runtime exceptions."
642
642
]
643
643
644
644
0 commit comments