WIP: Add prepublish and postpublish scripts support to apm publish

[Glavin001]

See https://github.com/atom/apm/issues/372

I need some help writing the specs:

• 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?
• 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?

TODO:

• [x] implementation of what happens on apm publish
  • [x] run prepublish script
  • [x] check if it exitted successfully
    • [x] show error message if applicable
    • [x] continue if successful
  • [x] check if changes to staging area and commit if available?
    • [x] commit message in the form Prepublish #{pack.name} for #{version} release
  • [x] continue to run publish as normal, which includes incrementing version and publishing to apm API
  • [x] run postpublish if all successful
• [ ] specs for publish
  • [ ] prepublish with success
  • [ ] prepublish with error
  • [ ] postpublish
• [ ] validate coding styles
  • specs: https://github.com/atom/atom/blob/master/CONTRIBUTING.md#specs-styleguide
  • CoffeeScript: https://github.com/atom/atom/blob/master/CONTRIBUTING.md#coffeescript-styleguide
  • Git Commit messages: https://github.com/atom/atom/blob/master/CONTRIBUTING.md#git-commit-messages
• [ ] documentation of any added internal code

[Glavin001]

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

[kevinsawicki]

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

[Glavin001]

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?

[bronson]

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.

[Glavin001]

@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.

[iam4x]

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

[steelbrain]

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

[Glavin001]

@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! :+1:

[danielbayley]

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

[idleberg]

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.

[aminya]

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.