purescript / roadmap

Long-term projects not covered by other issues lists
20 stars 1 forks source link

Package Manager #20

Closed paf31 closed 8 years ago

sudhirvkumar commented 8 years ago

@paf31 First, thank you for the awesome effort and changing our life forever. We are betting our company (http://atomicits.com/) on PureScript. We are training our whole team to work with PureScript and all our future (and current) projects will be using PureScript Full Stack (Web Apps, React Native Mobile Apps & Node.js Back End).

One thing we missed (would love ;) ) was a package manager which has the following features

  1. SemVer Packages and Package Manager tracks API changes and suggests (enforces) version number for the releases. Major, Minor or PATCH Release.
  2. Package Manager which will automatically keep packages used in the project up to date. "Patch" and "Minor" releases automatically upgraded.

    For example a previous "Minor" or "Patch" release cannot be installed... only the latest version will be installed. This will also make list of releases limited to the latest version. There wont be 1.0.1, 1.1.0, 1.0.2, 1.0.3, 1.1.1, 1.1.2, 1.1.3 etc... there will be only 1.1.3

    We can merge the minor releases's release notes so that people know the full history of changes.

  3. If a "Major Version" is released and current version used is older than say a month then a warning about the availability of latest version of the package(s) during project build.
  4. Auto safe upgrade (Minor and Patch releases) dependencies of packages used.
  5. JavaScript FFI code review: We can build community guidelines for writing good quality FFI code in packages, may be people can review the code and comment on it and rate the package as "Safe" / "UnSafe" etc so that developers have an idea when they try to use the packages and it will benefit the whole community. "Review Per Release" and review required only when there is FFI code and also there are changes in FFI code across releases. When using unsafe packages developers should get warning messages when they try to install the packages and also every time they build their projects.
  6. Before the package can be published, package should build successfully and should have no warnings.

    The above will really help developers keep reliability of their projects high up...

Also a few bonus points would be

  1. Package Manager which can Mirror the Packages a. So that we can cache the packages locally b. Reliability will be higher even when the package manager site goes down c. People can host their own Mirrors / reducing load on the main package manager site. d. We won't have to depend on github package repository or tags / releases, instead once published they are always available and people can't pull down the packages unless required by law or just generally good for the community.
  2. Recommended Packages Packages which comply with Community Guidelines, has better test coverage, Simple API, better documentation those packages can be "Recommended Packages" and we can tag packages as appropriate "Needs Better Documentation", "Needs more tests" etc so that it motivates Package Developers to keep the quality of the packages higher and also more people can collaborate.
paf31 commented 8 years ago

Hi @sudhirvkumar, thanks for the detailed message, and I'm glad to hear you've decided to use PureScript. I think lots of us would love to have a proper package manager with the features you described, but right now it's waiting on someone to own the project. I don't have time to work on it right now, but I'd be happy to help out with things like enforced semver by adding the appropriate things to the type checker.

rvion commented 8 years ago

@sudhirvkumar there is also relevant discussions here : https://github.com/purescript/purescript/issues/631

paf31 commented 8 years ago

This is being tracked in the compiler repo again.