eslint / espree

An Esprima-compatible JavaScript parser
BSD 2-Clause "Simplified" License
2.26k stars 189 forks source link

espree v8 release process #475

Closed mdjermanovic closed 3 years ago

mdjermanovic commented 3 years ago

After we merge https://github.com/eslint/espree/pull/469, we should update the release process to account for an additional build step.

The new build step (npm run rollup in https://github.com/eslint/espree/pull/469) does two things:

  1. Reads the new version from package.json to update lib/version.js.
  2. Creates dist/espree.cjs.

Current steps in generateRelease are:

  1. npm test.
  2. Update the changelog and commit that change.
  3. npm version to update package.json. commit that change, and create git tag.

But now we should have something like this:

  1. Update the changelog and commit that change.
  2. npm version to update package.json. commit that change, and create git tag.
  3. npm run rollup.
  4. npm test

An additional question is whether or not should we commit lib/version.js. It might make sense to have a fixed "master" (or "main") as the version string in the repo.

Previous discussion: https://github.com/eslint/espree/pull/469#discussion_r584326147

nzakas commented 3 years ago

I agree that it doesn't make sense to commit the changed version.js into the repo. It's a simpler release process if update the file during the release and then discard it.

nzakas commented 3 years ago

It looks like we can handle a lot of this complexity by using a prepare script, which will run before npm test and also before npm publish.