Use GitHub packages instead of release tags

[aminya]

This issue offers a new solution for the long old issue of APM and @atom that uses Git release tags for its packages.

The Solution

My solution is to use GitHub packages.

@github packages are available from npm, so the integration to apm is quite easy. We need to pass the arguments to npm.

https://github.com/features/packages

The Problems

• If we want to put binaries/transpiled/compiled files into the package, we have to commit them into the repo and upgrade them on each change.

  This means that people will have to download all the unnecessary files to use the package. This results in huge download sizes, which has caused numerous installation issues.

  For the developers, this is considered annoying compared to publishing a package to npm.

• If we decide not to commit the files, then people should download Gigabytes from npm devDependnecies just to build the code.

• We can not use a .npmignore in the repo. -> It has the same above-mentioned issues. For example, people should download the tests, docs, etc which can have a huge size.

• We can not support mono repo architectures with this

This is backward compatible

For the installation, apm should check if a package is registered using a GitHub package, and if not, fall back to the old release-tag method.

The old #498 issue:

The problems

• We can not have a .apmignore file in the repo
• If we want to put transpiled/compiled files into the package, we have to commit them into the repo and upgrade them on each change
  We can not support mono repo architectures with this

The solution

Create tar archive (or zip if you prefer) respecting ignore files and counting in files ignored by git repo from the local version of the > publisher. Add a release with the newly created tag and attach that archive with that release.

The release tag should be prefixed by package name, like linter-ruby-v1.1. The archive name attached to the release should be named package-name.tgz > or package-name.zip.

When installing a package, check for the latest tag in the APM database for that package, if the tag starts with package-name, try to find release for > that tag and download the package file. Otherwise, just download the zip archive of the commit as we do now. If we follow this pattern, we would be > backward-compatible with the already released packages.

I know the problems I mentioned above do not sound very important, but they are very annoying and very difficult to workaround.

For example basarat, blakeembrey and the rest of the atom-typescript team transpiles the typescript files and keeps them in their repo.

nmote ssorallen bolinfest and the rest of the nuclide team had to create a new github org facebooknuclideapm and create a repo in it for each > package they wanted to publish.

david-driscoll and the rest of the omnisharp-atom team also have to transpile typescript files and keep them in the repo.

devoncarew and the rest of the dart-lang team have to keep transpiled dart files in their repo.

steelbrain Arcanemagus and the rest of linter-eslint team has to commit transpiled babel files into the repo because we spawn a child process that > requires our files and child processes don't support babel requires

[aminya]

@sadick254 @darangi Will this ever happen?