fix: init event

[wraithgar]

For #1058

The init event was only being emitted during initialization of
a new repo. If one already existed that event was not firing.
This syncs up the behavior between these two situations so that they
log, set state, and emit identically.

[daviddias]

Thanks @wraithgar. Mind adding a test to make sure we don't break this in the future?

[daviddias]

This will failing linting (semicolons)

[wraithgar]

Sorry about that. Linting already reports 87 problems for me in master so that one got lost in the noise. Pushed a fix.

[wraithgar]

@diasdavid I'd be glad to add tests but would need a little help to be pointed in the right direction. As far as I can see in this repo there isn't anything testing the events firing. Am I just not looking in the right direction or would these be wholly new?

[daviddias]

See https://github.com/ipfs/js-ipfs/blob/master/test/core/create-node.spec.js

[Mr0grog]

Isn’t the point of the init event to indicate that the repo was init’d? This completely changes the semantics of that event and removes a useful signal (you can’t tell from the outside whether init will happen; the boot process chooses to do so based on what it finds at the repo location). Also, it will emit twice here in the case where the repo does get init’d. That seems bad.

I feel like this event should be named something different that indicates what it is actually about. Maybe prestart or prepared or repo-opened or something?

[wraithgar]

It won't fire twice here.

In boot.js, self.init is only called if maybeOpenRepo returns false, and the callback after the emitted init event returns true to the callback.

As far as the semantics of the init event, this is what I thought being discussed in #1058. I may have misunderstood. It would be possible to just emit a peer or repoevent once the peer is set instead in the pre-start component.

[Mr0grog]

It won't fire twice here.

Ah, you’re right; I misread.

As far as the semantics of the init event, this is what I thought being discussed in #1058.

I don’t think the semantics of the event really got any discussion there, though. Nobody actually said what the event was doing was wrong or unexpected — only that it didn’t fit @pgte’s use case.

I think there are two different things in that issue that make more sense to address:

• Is ready always emitting when constructing an IPFS node (assuming it didn’t have any errors)? If not, that’s probably a bug that needs fixing.

• @pgte’s specific ask was “I would like to have an event that tells me once the peerId is known.” Does the above with ready solve that? If not, what’s the right event to add? It’s probably something right where you added init here (or maybe inside preStart), I just think it needs a different name because it’s a different thing :)

[wraithgar]

If it's a new event it makes sense to do it right in pre-start after self._peerInfo is defined (because from that moment on calls to self.id() will return something).

[wraithgar]

The matter of ready always firing also does not meet the use case, from what I can tell. I think he simply wanted to know the moment that a peer was known so that operations that required one could start, without having to wait on the swarm et al operations to consider themselves ready.

[Mr0grog]

Fair enough! But maybe useful to wait for feedback from @pgte and some discussion on the original issue to zero in on the right change before continuing with the implementation here?

[alanshaw]

@wraithgar can this be closed? Reading the comments above it sounds as though the init event is being fired correctly already?