Would some of the maintainers of Atom / apm be able to give me some points on the questions above? Thanks in advance!

Should I run git init to make the temporary directory a Git repository and then it would no longer error with Package must be in a Git repository before publishing...?

How do I get past Package must pushed up to GitHub before publishing?

For both of these, you can create a repository locally that satisfies these conditions, and check it in to spec/fixtures and then you can just copy it to a temp folder and use it in the specs.

To confirm, once I get past the above, I can safely run publish and it will not attempt to publish to the global apm API because ATOM_API_URL is set to http://localhost:3000/api?

Yup, as long as ATOM_API_URL is set to a localhost address no calls will go out to atom.io

How do I get past Package must pushed up to GitHub before publishing?

For both of these, you can create a repository locally that satisfies these conditions, and check it in to spec/fixtures and then you can just copy it to a temp folder and use it in the specs.

So in the case of the Package being on GitHub, wouldn't a new tag be pushed every single time the tests are successfully run?
See https://github.com/Glavin001/apm/blob/master/src/publish.coffee#L445-L448 calling @pushVersion and @waitForTagToBeAvailable.
This does not sound ideal for testing to me.
Also, I believe that it would even error on the second run because the Git repo in spec/fixtures has the tag, say v1.0, and that version tag has already been previously pushed to GitHub, so it will fail this second time.

I was thinking along the lines of giving the repo a fake upstreamUrl and then mocking pushVersion and waitForTagToBeAvailable functions such that they callback successfully without actually sending requests to GitHub.
Thoughts on this implementation?

Question about potential usage... Any chance I could write a prepublish script that would use git log to fake up a new entry in the CHANGELOG and open it in an editor? Then, when I save the changelog entry, the package would be published as usual.

@bronson: Absolutely! This will wait until the prepublish script returns with it's exit code and will only continue afterwards if it was successful. That's a good use case. Personally, I will be using this for running a task for documentation generation before publishing.

Hey @Glavin001 any update on this? Do you need help?

Just a side question: Why are we using the callback-hell when promises are available?

@iam4x : I have not made any progress since my last commit. Any help would be appreciated. Unfortunately, I am now studying for my university final exams and will not have much time to work on this in the next few weeks.

@steelbrain : I would definitely prefer to use promises! 👍

Shouldn't this be expanded to include all relevant hooks? For example preversion/postversion…

I have noticed that Visual Studio Code prefixes its prepublish script in the manifest. I wondered if it should be considered a good practice to use atom:prepublish instead to differentiate from npm's script – not that I could think of a real life conflicting situation.

Could you fix the conflicts? This seems like a very critical feature that is missing from apm. Other features can be added in a separate PR.