Prepare for canary release #352
Conversation
ctavan
force-pushed
the
prepare-for-alpha-release
branch
2 times, most recently
from
b542770 to
c0e16d0
Compare
|
As stated in the commit message this is really mostly personal preference. I find Do you have strong feelings against yarn? |
|
My main concern with yarn is that it's yet another dependency in the toolchain that consumers / contributors need to be familiar with if they want to dive into the project. It's not that big a deal since it's only surfacing in the README as part of the build instructions for the examples and testing. I guess my preference would be to avoid it unless it's adding real, tangible value, but I'll leave that up to you. I recognize that this is something I'm probably more sensitive to than most folks. :-) |
Apparently the changelog for v3.3.3 was edited manually and had a bad heading level
ctavan
force-pushed
the
prepare-for-alpha-release
branch
3 times, most recently
from
5eef34c to
3660de9
Compare
"build" seems to be the more appropriate term for what we're doing here. Part of #343.
ctavan
force-pushed
the
prepare-for-alpha-release
branch
4 times, most recently
from
3005b50 to
db9aa7a
Compare
|
@broofa after getting more familiar with Moreover I have changed and documented the I would now go ahead and introduce the breaking change of removing insecure RNGs (#173) and then put out a first Would like to put the functional changes into yet another PR though. |
README_js.md
Outdated
| @@ -297,3 +297,13 @@ Type `uuid --help` for usage details | |||
| ```shell | |||
| npm test | |||
| ``` | |||
|
|
|||
| ## Releasing | |||
There was a problem hiding this comment.
Is this relevant to users of this module? Only a very small handful of people will care about how the release process works. Consider moving to a wiki page for project maintainers?
There was a problem hiding this comment.
Following this logic, the documentation on how to run the unit tests also wouldn't belong into the readme.
I moved both into the new CONTRIBUTING.md file. I personally find it hard to impossible to keep the wiki in sync with the code and would therefore prefer to keep such documentation within the repo.
package.json
Outdated
| "runmd": "1.2.1", | ||
| "selenium-webdriver": "~3.6.0", | ||
| "standard-version": "7.0.0" | ||
| "@babel/cli": "^7.8.3", |
There was a problem hiding this comment.
Change .npmrc to have save-prefix="^"
(For the record, I'd be okay removing version prefixes altogether so we have explicit versions throughout.)
There was a problem hiding this comment.
I switched to explicit versions.
Since the devDependencies are pinned in the package-lock.json anyways there's no real use in leaving a version range open for the devDependencies in package.json. Instead, we simply keep our toolchain up-to-date with tools like ncu. With this commit I also re-generate package-lock.json from scratch.
ctavan
force-pushed
the
prepare-for-alpha-release
branch
2 times, most recently
from
8bcf458 to
fd69d1b
Compare
Since we have a build step now we must point the package.json file reference to the dist folder and must explicitly list all files that we want to be included in the npm tarball. The initial idea was to prepare the contents of the final npm tarball all in the dist directory (including a copy of the package.json) but that turns out not to work particularly well with standard-version which is used to manage the version numbers and changelog. Unfortunately this change also required a small workaround to allow local installation of the uuid module in the examples (see .local/). Also instructions for relasing a new version have not yet been documented which is finally done here. Since we now explicitly list all files to be included in the tarball through the files property of package.json we no longer need the .npmignore file.
ctavan
force-pushed
the
prepare-for-alpha-release
branch
from
fd69d1b to
53ca9d4
Compare
This is a collection of a few more cleanup and tooling commits in preparation of a first 4.0.0-canary release.