0.3.2 does not work about aphrodite HOT 14 CLOSED

0.3.3 is published and pushed, 0.3.2 is marked as deprecated.

Thanks for the (incredibly) fast bug report, @goatslacker, and thanks @kentcdodds for chiming in so quickly :)

from aphrodite.

Thanks for reporting @goatslacker! Looks like the problem is probably the new .gitignore. I recommend that we actually add a files property to the package.json so we can explicitly list the files we want added (probably dist is all that's needed there).

from aphrodite.

it might just be that ya'll didn't npm publish the lib directory.

from aphrodite.

I recommend a prepublish script :)

from aphrodite.

Thanks for the report! Will investigate and fix.

from aphrodite.

Also, on the subject of prepublish, the workflow did have prepublish before, but I filed a pull request referencing npm/npm#3059 as a reason to remove the prepublish script. I have since learned that I misunderstood how prepublish works (which is reasonable because it's a bit confusing) and it's actually not too bad a solution after all. See my explanation.

from aphrodite.

Also, I feel compelled to bring up semantic-release again. Even though semantic-release technically wouldn't have prevented this, I still feel like it'd be a good thing to implement for various other human-error reasons :-)

from aphrodite.

Oh, and one other thing, just for completeness, let's make sure that 0.3.2 is deprecated

from aphrodite.

@kentcdodds I regret to say that I haven't taken the time to investigate semantic-release with any depth, but fear that the automatic version setting based on running against previous versions of the test suite will end up being more burdensome than helpful when not established from the get-go.

Thanks for the note about npm deprecate, I hadn't seen that before!

from aphrodite.

Okay, I've repro'd the issue and think I understand the problem. Here's what happened:

1. I cloned the repo fresh, having not set it up on this laptop before
2. I ran npm version to bump the version
3. I ran git push (this step is actually irrelevant, but just for completeness)
4. I ran npm publish.

The key thing is that npm build was not run anywhere in here, which is the problem. lib is intentionally not checked into the repository, but it is important that it happens before publish.

So the problem is in process, not in the codebase. Both the .gitignore and the .npmignore are correct (since the .npmignore trumps the .gitignore, allowing the lib directory to be published).

Following those exact steps again would avoid this problem, as #85 (merged after 0.3.2) makes the build step part of the version bump.

from aphrodite.

Oh, I just realized that the reason the build wasn't run is because the script version isn't run when you run npm version (only when you run npm run version). So you could add the build as part of a preversion script and that would work.

On semantic-release. I've added it to several projects after the initial release (I even demonstrate this in my egghead course) and it works great.

fear that the automatic version setting based on running against previous versions of the test suite will end up being more burdensome than helpful

Not certain what you mean by this. Care to elaborate?

from aphrodite.

@kentcdodds the version script is run when you run npm version. The problem was that 0.3.2 was published before I merged that PR (I'm guessing you wrote this before I wrote the comment about that).

Not certain what you mean by this. Care to elaborate?

Ah, sorry - I misread the description of the package, and assumed the bits about test suite analysis to be part of semantic-release, when it looks like that's actually functionality of a plugin. Looks like by default it just analyzes commit messages.

Others may disagree, but my general stance is to keep dependencies (both in process and in files-that-wind-up-in-the-repo) to a minimum, and so far I'm not seeing it as a big enough win to merit introducing it as a process dependency.

from aphrodite.

I'm guessing you wrote this before I wrote the comment about that

Yup! Thanks for clarifying :-)

keep dependencies to a minimum

I agree generally

I'm not seeing it as a big enough win to merit introducing it as a process dependency.

Yeah, this is what I hear most often when encouraging people to give semantic-release a shot. I should probably come up with a better "sales pitch" for the lib. But from my perspective, once semantic-release is set up, a whole class of (boring) problems just goes away and one of the most human-error prone aspects of maintaining projects is now automated. semantic-release is one of the most valuable aspects of my OSS workflow.

from aphrodite.

Thanks for fixing real quick :) I just bumped down to 0.3.1 in the meantime. 0.3.2 was testing my understanding of node, I would cd into a directory and type require('aphrodite') in a node REPL and I'd get module does not exist error haha

from aphrodite.