Remove releases/ folder

[ronyeh]

Coming soon in a separate PR: a script based on npm ci that will download any old releases you specify, to support visual diffing between versions.

In a future PR: an interactive script automating the publishing of the NPM package, that is a bit less magical than grunt-brump and grunt-release.

[ronyeh]

OK this one is ready to go.

It also fixes the grunt warnings, because it removes the grunt-release package which was last updated 5 years ago. (The bad dependency was shelljs.) We can automate our NPM release in a different way through an interactive node script (that invokes npm commands and package.json scripts).

[0xfe]

Conflict to fix.

So what do we lose with this? Is there any information loss at all from not checking in the releases? Are NPM + git tags sufficient? Are map files preserved?

[ronyeh]

What information do we lose? That's a great question. To be extra safe, you could create a new repo called 0xfe/vexflow-releases/ which includes all the relevant release files for each version. The top level folders would be

vexflow-releases/4.0.0/
vexflow-releases/3.0.9/
...
vexflow-releases/1.2.93/
... etc ... 

But assuming that NPM doesn't disappear, we can always get the build files for any revision by doing "npm install [email protected]" This means old releases are also browsable via unpkg and jsdeliver.

• https://unpkg.com/browse/[email protected]/
• https://www.jsdelivr.com/package/npm/vexflow

Since I'm the one removing the releases/, I can commit to working on a script which pulls down the releases as necessary from npm (via npm install or npm ci).

Git tags are useful, assuming we never delete the tag, which would mean we lose the reference to the commit hash. But from version 4.0.0 onward, we no longer check in the build files, so the git tag will only take us back to the source files. We would still have to run the build again. So, if we want to be extra extra safe, we'd want to have a separate vexflow-releases repo. We can then install that repo as an optional submodule in vexflow, so that we could pull down old releases if necessary.

Regarding source maps: A comment by @sschmidTU #1231 (comment) suggested that maybe we don't need source maps on NPM. What do you think? :-) In my ESM branch I've temporarily disabled source map generation and 1) it makes webpack build much faster and 2) our build/ folder and npm package is super nice and clean looking. How often do you think people rely on source maps? If they need them, could they just build VexFlow from source and then turn on the sourcemap flag?

Anyways, let me know your opinion on source maps inside the NPM package. I think Simon said he just puts them in the OSMD GitHub release zip file, but does not put them on NPM.

[ronyeh]

Tested this, with no visual diffs (via npm run test:reference). After this is merged, I'll try to finalize the proper ES module support so Simon can build OSMD with a light version of VexFlow that includes only Gonville. After the ESM PR is merged and tested, I'm happy to declare beta 2. I can work on a script to pull down old release builds from NPM while folks are testing out beta 2.

[0xfe]

Ron, instead of a new repo, how about Github releases? I've used that with other projects, and it's really easy to setup and automate.

Re: source maps, we need it somewhere, not necessarily in the NPM packages. We could build and bundle them with the github releases too. The criteria here is that we don't want people to have to build source maps for a version, they should be pre-built and downloadable for reach version.

We can definitely remove them from default builds -- they're only needed for versioned releases.

[ronyeh]

Okay. GitHub releases sounds good. I haven't used it before, so will have to learn it.

[ronyeh]

This seems like a decent replacement for grunt-release. It works with GitHub releases.

https://github.com/release-it/release-it

152,543 weekly downloads and last updated 2 days ago. Seems promising.

[0xfe]

Thanks Ron. Merging.