Mithril.js: Missing Bower.json in 1.0.0

[cetra3]

Hey guys,

Bower appears to be missing in version 1.0.0 onwards. Wondering if we can re-add support for the bundled version?

[barneycarroll]

Bower is redundant, unreliable, brittle and inefficient – use NPM instead!

[cetra3]

@barneycarroll, I've seen that argument before, and while I agree that it is old, that's not a reason to abandon it if it's working fine for me?

[isiahmeadows]

If anyone feels it's important enough, feel free to send a PR adding a bower.json and documenting how to install it (via bower install lhorie/mithril.js once it's done).

[tivac]

Seems like mithril doesn't need a bower.json to be installable via bower?

https://stackoverflow.com/questions/19348076/installing-a-dependency-with-bower-from-url-and-specify-version#19349338

[cetra3]

@tivac, you still need the bower.json to know what file is the main asset to include.

I will raise a PR.

[barneycarroll]

@barneycarroll, I've seen that argument before, and while I agree that it is old, that's not a reason to abandon it if it's working fine for me?

@ceta Jaakko Salonen isn't saying library authors should stop providing bower.json because "it's old" — he's saying (in a lot of detail) that Bower is an inferior and redundant tool that should be discouraged. The reason to abandon it is because it's bad practice and anybody capable of using Bower already has NPM installed and can (and should) use that instead.

It will take you less time to add Mithril v1 as an NPM dependency than it will to write a bower.json and make a pull request, and you will be better off for it. As Dan Abramov says in the thread you linked, demanding that new versions of modern libraries maintain (and thereby encourage) Bower packages is asking for other people to do more work to maintain bad practices in order to avoid better practices in user land.

Reading between the lines of your conversation with Dan, it seems the reason you want Bower packages is that you need global installs and can't have UMD code which relies on a global define. Mithril v1 is carefully packaged to provide a global m and does not use define as per AMD (another legacy practice), so this shouldn't be a problem.

Are there any other issues you're having with the NPM package?

[cetra3]

@barneycarroll,

Once again, I'm not advocating that everyone uses bower. I know that it is out of date, but at the moment it's working for us.

The reasons we still use it might be unique to our own requirements:

• No transpilation: We don't want to have to rely on webpack or browserify to bundle our apps. If bower breaks in the future, then it's still a very simple operation to generate a bundle (just concatenate some js files). This is pretty much the KISS principle in action.

• Separation of concerns: In a project, what NPM package is utilised for the front end, what is not? What files can I use within a module that are made for the front end? There is a main field, but is that frontend or backend? What about CSS? Is there a main_css field? If I upgrade this module, am I only effecting the bundling of the app, or am I potentially changing the front end activity?

• Established tooling: Our CI infrastructure, documentation, known "gotchas" and verified and QA'd deployments use bower currently. While we do have a roadmap to move away from bower eventually, the cost of doing so is high, so until it breaks we'll still be using it

[orbitbot]

I don't want to appear to sit on a particularly high horse, since we're also using bower for some stuff at work that hasn't been properly updated in ages, but;

• No transpilation [...]

This is hardly related to which package management tool you are using, rather what form packages are published with them. A fair bit of common packages are still distributed solely or additionally as UMD (certainly front-end libs), so concatenation should still be possible as a bundling technique. If anything, you might need to define the proper order of concatenating the dependencies.

• Separation of concerns [...]

It seems to be more a question of code organisation rather than tooling, unless I'm misunderstanding something. If you have a monorepo structure, putting the front and backend dependencies in different folders with separate package.json files would probably be a good way to start some restructuring that might be a good idea in any case. I was actually also concerned about unclear separation before moving completely to npm-based repositories, ultimately I do however believe the underlying cause was having front- and backend code in the same repository without (at least) having clear separation of concerns inherit in the folder structure there. We solved it by extracting the front end code into a separate repository.

• Established tooling [...]

While I do understand that this may be a pain, I'm not convinced this necessarily is all that significant a step. It certainly wasn't for us setting up scripts with other tools, automation is automation, and depending on which dependencies you're using and how they're distributed, ofc, migration may actually be fairly lightweight (changing repo structure isn't strictly _needed_ if you can manage the cognitive dissonance for a while).

[cetra3]

This is hardly related to which package management tool you are using, rather what form packages are published with them. A fair bit of common packages are still distributed solely or additionally as UMD (certainly front-end libs), so concatenation should still be possible as a bundling technique. If anything, you might need to define the proper order of concatenating the dependencies.

It sort of is related, because bower is front end only, so you can assume (relatively safely) that the main file is browser-ready. NPM is primarily for running nodejs applications and, just because they share the same language, doesn't mean that they are all compatible or run in a browser.

It seems to be more a question of code organisation rather than tooling, unless I'm misunderstanding something.

You're right, you can have seperate modules for front and build. What it means with bower though is you can clearly identify the intent. If you see my project and see the bower.json file you know it's only for the browser immediately. You could have a common layout or structure, like a front and build directory or similar, but it means things get more complex.

While I do understand that this may be a pain, I'm not convinced this necessarily is all that significant a step.

I haven't given all the details, but let's just say there are business decisions at work that are out of my control... There are more than just developers that would be effected by this decision.

[isiahmeadows]

Closing, since this issue has not been updated in over a month, and typically, issues inactive for that long do not usually produce any action. If you feel something in Mithril needs added or changed, please file a new issue.