twbs
Atmosphere package for Bootstrap is no longer compatible with Meteor 1.10 release
Meteor 1.10.x has some breaking changes for the version of Bootstrap that is hosted on www.atmospherejs.com - it will not allow the package to install because the version of Bootstrap in the package wants to downgrade the version of jQuery that Meteor 1.10 uses to 1.11.1 from 3.0.0.
For those who are attempting to install Bootstrap for use with Meteor via the [package management system, it is no longer able to be installed. Here is the output from the console when trying to install:
=> Errors while adding packages:
While selecting package versions:
error: Potentially incompatible change required to top-level dependency: jquery 1.11.11, was 3.0.0.
Constraints on package "jquery":
* [email protected] || 3.0.0 <- blaze 2.3.4 <- blaze-html-templates 1.1.2
* [email protected] <- twbs:bootstrap 3.3.6
To allow potentially incompatible changes to top-level dependencies, you must pass --allow-incompatible-update on the command line.
This package is long overdue for an update, as it was last packaged with 3.3.7 in November of 2015, but as the official producers of the package, it would be nice to get it upgraded to the latest bootstrap version.
Feel free to submit a PR to fix it. We don't use that package manager.
@mdo that's why I insist that we don't support package managers we don't control nor test... Something that isn't tested is bound to break.
Okay, I'll look into what needs to be done to package the most recent version of Bootstrap for Atmosphere's package management and then put it in.
To be fair, this is likely more of a factor of Meteor being bought by Tiny and pushing out a few sizeable releases within the last 6 months after being pretty sparse with the releases in the late 2010's. Atmosphere also stagnated in use and adoption as most developers went to NPM, so it would have been easy to lose track of, even if someone else on the Bootstrap development team packaged it for Atmosphere back in 2015.
@XhmikosR Just to know, couldn't we add some action on release event or something to test some package managers installation?
I think there is a publishbot that is attached to twbs’s atmospherejs.com account that will vet anything that comes through once an updated package.js file is merged into the version release branch. I closed these pull requests because back in May, I really had no idea how to work with other devs collaboratively on PR’s (even though I knew how to fix the issue) and quite honestly for that reason, they were a bit of a mess. Now I have a dev job and review them daily so I could re-fork the repo, open a fresh PR and it’d be a much tidier one.
Sent from my iPhone
On Nov 23, 2020, at 6:13 AM, Gaël Poupard [email protected] wrote:
@XhmikosR Just to know, couldn't we add some action on release event or something to test some package managers installation?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
@sarahmattar sorry for not responding sooner to your PR, I honestly still have it in my backlog :)
That being said, my main issue is that I have no knowledge of meteor.js nor how it works. Also, v4-dev requires jQuery, while the main branch doesn't. If you think you can make things work again let us know and I'll really try to respond faster next time.
Ah okay. Here is some backstory on Meteor, as there is a concurrent evolution between Meteor and Node which explains the package system:
Meteor is a fullstack platform built on Node. It integrates MongoDB and front-end rendering engines like React, Blaze, and Vue, and has some extra proprietary libraries. It's been around since about 2012. Initially, to accommodate these fullstack capabilities, Meteor developed it's own package management ecosystem. Developers could add packages to their projects by typing, for example, meteor add twbs:bootstrap into the command line. This is how atmospherejs.com was born - it is the user-facing website for Meteor's central package repository. Meteor keeps a record of all packages installed in a project inside a proprietary folder and compiles the specified versions at runtime.
In version 1.3 of Meteor, they began to allow NPM dependency installation alongside Meteor's native packages. Since Meteor's packages were not stored in node_modules, so there was no real risk of collision when installing NPM dependencies. NPM dependencies could be installed by prepending meteor to the usual npm install command (i.e - meteor npm install bootstrap). By 2015, Node was gaining in popularity and more NPM package dependencies were being produced, so Atmosphere packages began to fall out of favour. Atmosphere package development began to languish in 2016/2017... but at the same time, Meteor Developer Group was focusing most of it's attention on Apollo (GraphQL client) which had taken off, so Meteor itself got minimal attention and minimal updates were pushed out over the last years of the 2010's. This meant most outdated Atmosphere packages that simply relied on the latest version of a Meteor-published packages (like jquery) did not break until recently.
Fast forward to 2020: Meteor has been acquired by a new company, and they suddenly begin pushing out updates to their own platform - they've had about 5 releases in the last 11 months. They also updated their Atmosphere package versions with the new releases (jquery went from version 1.11.11 to 3.0.0), and that broke many packages that relied on the old package version (like Bootstrap).
TL;DR: To go forward and fix the package's dependency versioning, we would need the login details for twbs's Atmosphere account to upload the updated package.js file (unless the publishbot listed on the package details page will detect the change and do it for us). There hasn't been anything pushed to Atmosphere in about 5 years, so the latest version on there is Bootstrap 3.3.6. Dan Dascalescu is listed as one of the people associated with the TWBS account: is he still around and contributing?
Here is what I have done in another PR to update jquery's version dependency. It took a couple of tries to get it right, but it should be both backward and forward compatible with new and older versions of Meteor. What I would do in a fresh PR is update the package.js file with the latest dependency versions for Bootstrap4 version against the v4-dev branch. (I realized after replying to your comment earlier via email that I meant to say v4-dev instead of main branch - it was early and I was just waking up!). Then we could push the update to package.js from v4-dev to Atmosphere's package server.
If we can get full login access to the Atmosphere account, I would propose creating a legacy bootstrap3 package, update the jquery version numbers, and push your v3-dev branch to it. Reserve the bootstrap name for the latest stable release. When that is Bootstrap 5, we could create a legacy bootstrap4 package to house Bootstrap 4's long term support release. What would you think of that?
