Can't publish with semantic-release (over existing module?) about semantic-release HOT 19 CLOSED

@remy npm publish is now being run on travis for you, you don't publish yourself anymore, it's happen for you, whenever tests pass and there is a patch / minor / major change in the commits since the last one, via your travis deploy settings

You can still run npm publish locally, see this question:
https://github.com/boennemann/semantic-release/#how-do-i-get-back-to-good-ol-npm-publish

Note, this one applies to your project as well, because you test on multiple Node versions:

Note: If you have a more sophisticated build with multiple jobs you should have a look at travis-after-all, which is also configured for this package.

Ping me if anything is unclear :)

from semantic-release.

btw it's BREAKING CHANGE:, not BREAKING CHANGES:. But maybe it works with both, I don't know :)

from semantic-release.

Huh, that's weird. I did check the npm version (via the web site) and it still said 0.1.2 not 0.2.0 as it does today...

So this isn't actually a problem then... weird. ¯_(ツ)_/¯

from semantic-release.

Do you know if the commit format allows for skipping the (something) part after the type, or should I go ahead and my own parser?

from semantic-release.

@gr2m Thanks for clarifying this.
@remy It's totally fine to skip the (<scope>) part of the commit message. Just feat: <message> etc. works.

from semantic-release.

@remy the npm website has caching, the displayed versions are sometimes out of date. They are working on a smart "invalidating cache" script right now. Raquel is talking about it on the last episode of descriptive: http://descriptive.audio/episodes/18

from semantic-release.

Erm...following up on this, I've noticed that the version in npm has actually gone a bit stale, and I'm sure I could push to npm directly and it'll update.

Two examples - it doesn't contain the latest readme but also doesn't have v0.2.1 (the latest version)...

I'm not terribly confident of when it's actually being pushed to npm or not...

Checking npm view bind.js, it seems that npm doesn't know anything about 0.2.1.

from semantic-release.

I dug in a little further, and can see this from npm: publish Failed PUT 500. I'm going to try to re-encode my auth details.

from semantic-release.

Okay, so I got to the bottom of this. I ran the commands from the README to add travis fields on the CLI and pasted them into my .travis.yml file. Because I didn't use the --add CLI arg, it all kinda messed up. I say "kinda", it really messed up.

But now I have new problems - this: https://api.travis-ci.org/jobs/64443174/log.txt?deansi=true (see "something went wrong")

Any clues?

from semantic-release.

Note - I went ahead and tried to manually remove the duff releases. I think it might be worth either having a cli to prompt for the .travis.yml bits (I saw an issue on this already), or making it super clear that you need to include the --add...or maybe it was, but I thought it would overwrite my travis file ¯_(ツ)_/¯

from semantic-release.

@remy Sorry for the hassle here. The setup part isn't really that seamless and I'm already thinking of ways to streamline all of this.

Generally when there is an unwanted version I unpublish it npm unpublish [email protected] and then manually set the latest back to the version before npm dist-tag add [email protected] latest.

Do you think we can close in favor of #29, or are there remaining issues that we need to sort out?

from semantic-release.

@boennemann I did unpublish the latest v0.0.0-semantic-release tags, but I have a feeling that something's still wrong. I just pushed a change to github, and travis failed the deploy again: https://travis-ci.org/remy/bind.js/builds/64635839

I think there's two issues - one is definitely some kind of streamlined setup - and I kinda feel like there's some mistake I made early on that's causing pain now - so this would be awesome if done right.

The second issue is what I've got now: stuck on the v0.0.0-semantic-release version.

from semantic-release.

One thing that probably is a problem here is that the placeholder number (v0.0.0-semantically-released) must be a yet unpublished version, because npm does some checks on it that aren't too useful in our case :/
Try changing the version inside your package.json that's checked into git to v0.0.1-semantically-released or similar. Heads up: The version inside the package.json doesn't have anything to do with what's published later on :) (well, at least that's the plan…)

I'm definitely trying to ease all of this and I'm also visiting the npm offices next month, so I have a clear idea of what makes sense for the future path.

from semantic-release.

With semantic-release@4 there is no more requirement for a placeholder version in the package.json, which is why these problems should ultimately go away :)

from semantic-release.

@boennemann you need to remind me where to get the version from npm again...

Also - good have dinner and chat with you! :)

from semantic-release.

@remy Yeah, I enjoyed the evening a lot!
You can get the new version using the CLI: https://github.com/semantic-release/semantic-release#setup

We should chat about the bigger picture setup, once we have done that for hoodie ourselves :)

from semantic-release.

Semantic CLI - I'm all over it!

Also - that npm url you showed me...the one that responds with JSON, can you remind me of the url?

from semantic-release.

@remy

normal package: https://registry.npmjs.org/semantic-release
scoped package: https://registry.npmjs.org/@semantic-release%2Ferror

You can also use the cli (which should be easiest if you want to get info about private packages)
npm info semantic-release --json.

It allows you to query individual fields:

npm info semantic-release versions --json
npm info semantic-release version --json
npm info semantic-release dist-tags --json

from semantic-release.

Very useful, thank you!

from semantic-release.