restore bundle downloads

[gordonwoodhull]

1760 points out that the crossfilter download link is wrong.

Actually the dc.js download links are wrong as well, since we stopped checking in artifacts:

• one points to the GitHub Releases; these zipfiles do not include the bundled dc.js anymore
• the other link points to the repo, which doesn't work for the same reason; this link should be deleted

This was previously raised on the user group and I created one bundle release manually for 4.0.0. But I didn't automate it, so that was the last GitHub Release.

We could use something like release-it. If we want to be really fancy, we could copy the corresponding section from Changelog.md as the release notes.

(GitHub Releases are neat but it feels wrong to me to keep the changelog outside the repo, especially if we ever have to move.)

[kum-deepak]

Since we have started using GitHub actions, we can run more things automated. These workflows can target even specific branches. It should be possible to create a workflow that triggers upon push to the Master branch.

[gordonwoodhull]

Nice... yes, if we figure out the right trigger then a GitHub action would be more convenient.

To be precise, it's when a new numbered tag is pushed, but usually master is only pushed on release of a new version, so that could work too.

[kum-deepak]

Another, low tech, version could be like something:

• Public release only through NPM, i.e., npm install or CDNs linked to NPM.
• It does not cover the case if someone wants to install from a PR (or branch) that we are not going to merge. In such cases we can write a script (or grunt task) that builds, tests, changes the .gitignore, git-add, git-commit, and git-push.

Does that cover all common cases?

In addition, we can add instructions to how they can build (we know that it builds on Windows, Mac, and Linux).

[kum-deepak]

I think people will keep switching to bundlers or direct ES6 imports (as the support matures).

[gordonwoodhull]

I hear you, but we can't assume that people use modern tooling.

Many of our users build their sites manually, and some don't even use npm. As far as I can tell, there is no way to download a package from npm. You have to create a package.json and do npm install. Or curl it from unpkg.com. 😛

dc.js appeals to data scientist types, who are not necessarily well versed in JavaScript - they know Python or R or something else. It also appeals to novice programmers. I think that's great.

I've gotten a lot of pushback when I suggest that people learn how to build dc.js. grunt is a lot of conceptual overhead for someone who just wants some charts.

Good point about branches that we don't intend to merge. There are features like grouped bars that are unmergeable in their current state. We used to suggest installing the branch via npm and a github link, but that no longer works since we don't check in artifacts. A GitHub Release would be perfect for that.

[kum-deepak]

Let us split it into two groups of users. One that wants to use public releases and the other who want to use PR/branches.

For public release users:

• We make unpkg links as a preferred way.
• We provide a snippet on how they can use directly those URLs.
• We provide instructions to save a local copy if they want to (right click and save as).
• We make it clear that they need to use one of the JS (full or minified) and the CSS.
• Alternatively, if they are using a bundler, they can use npm.

For PR/branches:

• When we decide that a particular branch/PR won't be merged any time soon, we add assets to the git branch.
• Until that stage, if someone wants to use, they would need to build their own. If someone raises an issue, we can consider adding assets to that branch.
• We can provide instructions to save .js (.min.js) and the .css locally to use it.
• We can provide instruction that they can use npm install from the git branch if they wish to.

Does it cover all cases?

In addition, we may switch to using unpkg URLs in our stocks sample and other examples in GitHub pages. This can be done before deployment, so, that our testing workflow is not impacted.

[gordonwoodhull]

I guess you are concerned about adding extra infrastructure to publish release zips on GitHub, and the extra maintenance required by having more infrastructure.

I respect that.

And I agree that save-as links aren’t any harder than release zips.

And finally I’m okay with checking in artifacts in some branches but not others. It’s messy but it should work well.

What this proposal doesn’t address is populating the GitHub Releases. At least the one person on the users group expected to be able to download the current bundle from the Releases page. I don’t know if other people do. We probably have documentation pointing to the Releases page.

So... I don’t know if its worth supporting. When I explore other people’s projects I never know whether I should look for a changelog or look at the Releases page. Maybe it’s nice to have both, or maybe duplication is an invitation to error.

Interested to hear your thoughts on this, and willing to close in favor of changelog-plus-unpkg-plus-occasional-artifacts.

[kum-deepak]

Sorry for not being clear. I am not all saying not to maintain the GitHub release zip files.

I am trying to figure out what will be an ideal set of ways that we implement. One of those can definitely be GitHub releases. I do understand that it can be redundant as well.

Currently, my preferred ways would be ways that can be automated (including our documentation links).

I understand that dc is quite popular and used by people with a variety of skills. In making decisions, I would propose that it should be simple for users with lower-tech skills. As the higher-tech skill people would be able to use techniques like bundlers and npm.

[ufundo]

Hi there - sorry to bump an old issue, but I'm after a zipped release link for 4.2.7 for including in the build pipeline for CiviCRM ( https://github.com/civicrm/civicrm-core )

Is this still planned?

If so I don't have much experience of Github Actions but would love to help in any way I can :slightly_smiling_face:

[kum-deepak]

It is possible to download the gzipped tar from npm. The following command will give you the tarball URL:

$ npm view dc dist.tarball

# or, for a specific version
$ npm view dc@4.2.7 dist.tarball

# As of 04 Aug 2024 it gives
# https://registry.npmjs.org/dc/-/dc-4.2.7.tgz

You can download this file and use it locally.

[ufundo]

Ah I didn't know that was possible, but looks great. Thank you @kum-deepak !