So we can publish with .e.g. a "browser" keyword:
npm/npm#4321 (comment)

Trying to release QUnit 1.19.0 I'm getting a exceeded API rate error on the changelog task.

Here is a gist with the full log: https://gist.github.com/leobalter/2036c590d050ed839c93#file-gistfile1-txt-L209-L221

It allows new and clean retries, but they all fail at this point.

Also, the fail says:

But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.

I wasn't able to find anything on the docs.

Right now projects need to include any additional dependencies in devDependencies in order to make them available inside the release script. For some projects, these dependencies may be quite large and having them around for normal development is unnecessary. It'd be better to only have these dependencies installed when the release script runs.

Would be nice if the changelog only included commits from one pre-release to the next, instead of all from the previous stable release to the current pre-release.

Make it small to speed up testing jquery-release, but include enough for the testing to be relevant. For example, needs to support grunt authors.

We can try to commit node_modules to speed up the npm install step. Should include one release-specific dependency that alyways install, but that should be tiny without transient dependencies.

Since grunt authors needs grunt, we have a rather big dependency. Should see if there's some way around that.

We can use this to also test error conditions, like an outdated AUTHORS.txt. We have to figure out to make use of that and implement it. One idea is to do branches for various error conditions, so invalid-authors would have an outdated AUTHORS.txt and nothing else. The change would be tiny (shift instead of pop on the read authors), so a rebase on master should always be trivial.

To automate testing of the release script, we could have a separate script that does something like this:

#!/bin/sh -ex
node release.js --remote=../fake-project --branch=master
# don't fail on errors anymore, capture them instead
set +x
node release.js --remote=../fake-project --branch=invalid-authors
## TODO assert that authors were invalid
node release.js --remote=../fake-project --branch=invalid-npm-owner
## TODO assert that npm owner is invalid

For that to be actually automatic, we'd need a way to skip the confirms.

Also need to remove tags and the cdn commit, something something:

../fake-project/git tag -d 0.0.1
../fake-project/git reset --hard HEAD^
../fake-cdn/git reset --hard HEAD^
../fake-cdn/git push -f

These currently assumes that everything worked, but that wouldn't always be the case.

To assert the output, redirect stdout (and stderr) to a file and grep them?

During a pre-release, we should verify that the specified version is valid.

Right now the tasks assume they know what directory we're in. To safe guard against new/changed tasks, we should explicitly set the CWD at the beginning of each task.

The signature should match Release.git().

We should have pending PRs to update all project-specific release scripts at the same time.

I would like to use this for my own project, https://github.com/jzaefferer/jquery-validation

Currently there is no way to disable the CDN upload, so the script fails there. I though I could just override the relevant methods, but since those get passed by reference (aka the references are copied) to Release._walk, my overrides come to late and don't change anything. For _checkAuthorsTxt this happens to work since _checkRepoState calls it.

A flag ala npmPublish, here cdnPublish, would help. If that's acceptable, I'd put that together and test it with my plugin release script.

Hi! I've noticed this repo defines an automated script to release jQuery org projects and this script allows publishing the project/package to npm. npm has recently enabled publishing packages with provenance and that could be a nice addition to jQuery org releases.

The provenance holds verifiable information about the software artifacts describing where, when and how it was produced. It ensures that the artifacts users download from npm were uploaded from a reliable source.

If you are willing to make a few changes to the jQuery org release process, we can publish the npm packages with provenance using GitHub workflows! If you agree, I can support you by opening PRs.

Additional context

I'm Gabriela and I work on behalf of Google and the OpenSSF suggesting supply-chain security changes :)

shouldnt this package use npm ci instead of npm install to make sure it only installs the required packages in the version which is defined in package-json.js

the release should contain what the host project defined in its package-json.js it should not try to find newer packes at release time.

see
https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable
https://docs.npmjs.com/cli/ci.html

See jquery/codeorigin.jquery.com@9415813

jquery/esprima#1085 (comment)

QUnit CDN files have naming very similar to jQuery itself, e.g. /cdn/qunit/qunit-$version.js. Currently the files would end up in something like /cdn/qunit/$version/.

Can we make the CDN path configurable? Or should I just update lib/cdn.js to hardcode a check for Release.project === "qunit"?

I know that those would be tricky to write, but no tests at all? Seems weird and stupid. Preferably ran in all supported node versions on Travis CI.

http://contribute.jquery.org/commits-and-pull-requests/#commit-guidelines

Stable releases should get tagged as beta as well so that anyone trying to use the closest to bleeding edge that we provide gets stable versions if they're newer than the most recent pre-release.

We should have abstractions around our common tooling. A Grunt abstraction will also allow us to stop handling the Windows difference directly in each project.

This line https://github.com/jquery/jquery-release/blob/master/lib/contributors.js#L6. It seems strange. Why not to use something like the array-unique module? It's considered best practice to have individual runnable functions in a separated (and tested!) module. Also, it's way more performant.

There should be a Release.confirm call between commit and push in the cdn task.

In cdn, use the name from package.json. In changelog, use the repo URL. Check if there's any project-specific scripts that use Release.project (that's very unlikely).

When a project was never published on npm, we can't check for owners. This doesn't matter for our existing projects, since they all were published before. Its easy enough to skip by uncommenting the call to Release._checkNpmCredentials, but some day we should probably address this.

Since there's no milestone with a name like "3.0.0-alpha1", GitHub changelog generation breaks because it should be using "3.0.0" as the milestone. I'm not sure the best way to fix this. Perhaps we could just do something like...

var version = Release.preRelease ?
    /^\d+\.\d+\.\d+/.exec( Release.newVersion )[ 0 ] :
    Release.newVersion,

    milestone = milestones.filter(function( milestone ) {
        return milestone.title === version;
    })[ 0 ];

instead of using newVersion, so it lops off any version labels.

From a recent release:

npm tag [email protected] beta
npm WARN tag This command is deprecated. Use `npm dist-tag` instead.

Haven't yet looked into the details.

Pretty much all our projects only have a single license, MIT. This script should support the single license in package.json, instead of assuming/forcing the licenses property.

See also https://npmjs.org/doc/files/package.json.html

Cloning the entire CDN repo takes a long time. We should at least allow the clone to stay on disk and pull updates, instead of forcing the __release/ dir to be deleted.

npm has a loglevel of warn that won't output all the http messages. I can be set with --loglevel warn, aka --quiet aka -q. I suggest we add -q to both npm install calls. It still outputs a summary of all the installed modules (and logs from install scripts), which is all we need. If something goes wrong, it'll output that as well.

on windows7 I am getting the following output

##
## CALCULATING VERSIONS
##

Validating current version...
We are going from '1.14.0' to 1.15.0.
After the release, the version will be 1.15.1-pre.

because of the single quotes arround the "current detected version" the whole release process fails

running my fork https://github.com/staabm/jquery-release against https://github.com/jzaefferer/jquery-validation

as the createTag step triggers commit hooks and the used commit message just is a version-number

Release.exec( "git commit -m '" + Release.newVersion + "'",
            "Error committing release changes." );`

it violates the jquery-validate rules of every commits needs to indicate/prepare a component, the whole process fails with a error from the githook.

could we either make it possible to define the commit message or make the commands not trigger hooks (not sure this is possible in git)

//cc @jzaefferer

This apparently saves some dangerous/places a release could go wrong situation, but I think that it's going to create problems for cross platform if the deps ever end up with compiled gyp modules for instance.

It's generally not a good idea to have them committed to the best of my understanding. Thoughts?

We use package.json as our canonical source for the version property, so bower.json should only be modified in the tagged branch. Currently _updateBranchVersion will incorrectly update bower.json in master (or whatever the branch is).

I suggest to change _updateBranchVersion to call Release._versionJSON( "package.json", Release.nextVersion ); directly, instead of _setVersion as it does right now.

For projects that publish to npm, we should verify credential up front to make sure we don't have permission problems at the end.

npm owner ls <package> will list the owners and npm whoami will list the current user.

Seems like currently this repo uses the colors module to get colors in the terminal. You'd better consider using an alternative, @sindresorhus chalk for example. colors.js has many disadvantages (see chalk's readme).

jQuery 1.x shouldn't get set as latest even for stable releases. Similarly, 1.x pre-releases shouldn't get the beta tag.

QUnit almost never has patch releases, so bumping bower.json and package.json to the next x.x+1.0pre before releases is something jquery-release could take over.

Major releases are relatively rare, so doing those manually is probably fine.

Seems like you've got some broken links in the readme:

You need local clones of fake-project and fake-cdn, then update both variables to point to those.

I can't seem to find the fake-project and fake-cdn projects (github is giving me a 404). Are those repos moved or do I need to use another repo?

For example, "Tagging the 1.11.0 release." is not a valid commit message, according to commitplease. Noticed this while starting the migration of jQuery UI to jquery-release.

Commitplease accepts commit messages that are just the new version number. We could use that, or come up with the "module" to put in front of the above commit message.

Move these out of the stable-only section and always run these tasks.

Core currently requires md5sum, UI requires unzip. Arguably those could all be replaced with node modules. Both UI and Mobile have their own implementation for creating md5 sums. Last I checked, there was no decent unzip implementation in node (archiver only does zipping; node's zlib wrapper only handles compression, not the actual archiving).

If we make the check extendable, we'd have move or duplicate it, since it can only run after _cloneRepo.

We should check for dependencies such as git, npm, grunt-cli, etc. at the beginning of the script.

If a task errors out, we should log all the state so we can restart the release process. When restarting, it should be possible to pick which step to start from, but there should be a sane default if that's possible.

lib/repo.js tries to loop over licenses that aren't there. PR incoming.