Bootstrap: Remove dist files from the repo

[XhmikosR]

I think we should discuss about doing this. They bloat the repo and its history a lot. And assuming we have a proper solution for releasing, which I think we do, we should be covered.

/CC @twbs/team

[ffoodd]

As you may read in how to publish your package on npm?, it's pretty easy to ignore dist/ folder from Git and still publish it to npm, by:

• [ ] ignoring dist/ from Git in the .gitignore file,
• [ ] adding dist/ folder to the npm package by adding it to the files entry in package.json.

I'm also thinking about this for our own fork (see Boosted #203) but haven't look further.

FWIW the first comment mentions publishing on Composer and NuGet, that may need dist files…

[Johann-S]

I think it's a good move to remove our dist files, we don't need to keep those files in our repositories.

So LGTM 👍

[mdo]

Removed from the v5 release for now.

Possibly dumb question, but does our test for bundle size need to have the dist files in the repo?

[MartijnCuppens]

@mdo, in the github actions script bundle size runs after the dist files are generated (by npm test):
https://github.com/twbs/bootstrap/blob/aa95f6d618691a8e14770106bb9dc5e75ea4170c/.github/workflows/test.yml#L41-L48

[XhmikosR]

My main concern is breaking any package managers that might expect the dist folder in the repo.

[MartijnCuppens]

Composer needs the dist folder indeed.

[MartijnCuppens]

What if we only include the dist files in the commits we're going to publish?

[XhmikosR]

I don't think that makes sense.

Hence why I suggest dropping any package managers that don't make sense for our use case.

[mdo]

We could also drastically reduce the number of files we generate and track in the dist directory. At this point, there's no reason to be including bootstrap.css when we have bootstrap.min.css—the former should just be to start.

If we do that, we nix eight CSS files (CSS and their source maps, since those are duplicated for regular and minified CSS) and another six JS files (once again for source maps and regular/minified duplication).

I don't mind the files being there. I remember there being some issues with changing around our files strategy for package managers previously—including dropping Bower—and that was a bit of an issue.

[mdo]

Thoughts on the above comment for dropping the non-minified CSS files?

[MartijnCuppens]

I think only composer is the problem here, only they rely on git. But:

• Composer is a Dependency Manager for PHP, not for frontend assets
• In many cases the vendor folder containing the packages is not accessible by web for security reasons, so the assets should be copied our symlinked, a setup which I think is very unlikely to have.

Imo, it's a good idea to drop composer support. We should encourage developers to use the right tools like npm

I don't mind the files being there.

I do 😛 It's annoying to see unrelated changes when I use git status or git diff.

[MartijnCuppens]

It seems there's also something called Meteor (we mention this on our homepage). I think this refers to https://atmospherejs.com/twbs/bootstrap and it seems like we didn't update this since v3.

Related: https://github.com/twbs/bootstrap/issues/29431

[supergibbs]

FWIW, I can work around this for NuGet package. I'll just add a step to run npm dist to build to dist/ locally, then run scripts to build the packages from that. I agree that pattern makes more sense than tracking the dist/ folder in git.

[XhmikosR]

I'll just add a step to run npm dist to build to dist/ locally, then run scripts to build the packages from that. I agree that pattern makes more sense than tracking the dist/ folder in git.

The thing is that this isn't safe. I mean, theoretically the builds should be reproducible, but the safest way would be to grap the release zip or use the npm package. Even if a single character is different, the integrity hashes will be different.

---

The only downside I see if we nuke the dist folder, apart from maybe breaking some package managers/integrations (which I'm going to be honest, I don't know for sure what will be), is that it can be handy to be able to see the dist file contents on GitHub.

[supergibbs]

Probably the best solution is to setup GH actions or some other tool to build, create a release, and then run all the deploy scripts to npm, nuget, etc. If any deploys fail, use the release zip to create the deploy. I don't know how much of this is automated currently but I am happy to work with the team on the nuget part.

[mdo]

Do we handle this in v5 or close as a won't fix?

[XhmikosR]

Unfortunately, let's close it as won't fix for now. We need to drop some package managers if we want to go this way.