Bower install

[amitgur]

Hey

I'm trying to use teoria with bower. After "bower install teoria" I can see the library and sources but there is no "teoria.js" file that I can use directly like other libraries.

[saebekassebil]

I actually haven't looked into how bower works. Looks to me like it just downloads the git repository. And no, there's not a shipped version of the build. Is there something particular you're trying to achieve with using bower, or can't you just use npm?

[amitgur]

I think the build file should be part of the repository. so doing bower install will enable us to use the teoria directly without building it localy. personaly I built it so for me it's OK

[panarch]

@saebekassebil I should reply for your message but I'm late and although this is another pull request, I apologize.

@amitgur I also thought last week and I made a build & sent the pull request and rejected. But I can also understand @saebekassebil's opinion.

For solving it, I wrote the scripts to run build for a previous project and now I started to use browserify, so there's no problem anymore in my case. or if you want to keep bower, you can make the build script using one of grunt, gulp or npm script.

[amitgur]

Thank you @panarch I'll make my own build

[fastfrwrd]

Bower, like npm, clones the project down from git based on a registered path in the Bower registry. The main difference is that bower is dedicated to managing client side dependencies only. At Picardy (http://picardylearning.com), we use bower for frontend dependencies and npm for backend dependencies. It helps keep our house in order quite a bit to have that separation. It's a very popular project.

I know this is a closed issue, but it is pretty redundant to have everyone separately build using jake. By checking in the dist and creating a bower.json file, the project would be much more friendly to those who use bower to manage frontend dependencies. If people want a custom build, your build steps are still valid and helpful for them, but I imagine most people who use Teoria use it as is.

I'm going to fork Teoria and add cursory bower support, and then keep the project in sync downstream and include that fork as a custom Bower module. I will PR that against this issue, but I understand not wanting to update your release process.

Thanks for making an awesome library!

[saebekassebil]

Hi @fastfrwrd. Wow! Can't wait to see Picardy evolving!

Building using Jake was a huge mistake - all the magic "//include" directives, are driving me insane, but they stem from a time where there wasn't any real alternatives.

Anyways. I'm working on splitting this library up in several smaller bits and making this module a kind of "glue" for all the modules. This will mean, that there is no build step if you're already using browserify/webpack.

I'm working on the modularado branch and I hope to release soon.

The problem I have with bower is that I feel it's redundant already, since we've npm, and npm basically works great with frontend dependencies already - really, you should try it. Another problem is that they clone the git register - which is not what npm does. In npm you upload your files to the registry, and this means that I can have a "prepublish" step in my package json that assembles everything and exposing a single file for users to consume.

I'll think about this a bit more, but basically I don't want to include the dist files in the repository

[fastfrwrd]

I understand that, for sure. If there's anything I can do to convince you of that (and to convince you to create git tags when you bump your package version, which is what bower uses to pick versions), then I'll try. 😀

Can I ask what your hesitation on checking in the built file is? Even without a bower.json file, including that would mean that bower users could directly import from the home repo instead of a fork like we will be doing now.

For reference about the lack of prepublish steps in Bower: http://stackoverflow.com/questions/17170500/how-make-bower-build-the-package

[saebekassebil]

Let me just reopen this while we're discussing it, to make it more public.

[saebekassebil]

git tags: yes I might just do that, although it's not particularly helpful to npm users (or needed since npm uses SemVer in package.json), it could help manage the repo a bit better.

Can I just ask what the issue is using npm? Separating modules into frontend = bower & backend = npm doesn't seem to add any value (and npm is also for frontend)

My issues with checking in the build file(s) is:

• it adds an unnecessary overhead to maintaining the module. Each time I (or a contributor) do a bugfix or implements a new feature, we will also have to remember to update the build files
• This will in turn clutter the git history.

Especially the first point is such a drag and so easy to forget.

[fastfrwrd]

It's not that I'm opposed to using npm for frontend dependencies. The browserify world has proven that it's a valid and great way to manage dependencies. But there's also a community of people using bower to accomplish dependency management on the frontend, especially those of us who chose to use AMD/RequireJS. It's a bit like UMD declarations in your module - you do them so that a wider audience of people can directly import your project. That said, you've got to draw the line somewhere and move on, so maybe this is your line.

I agree that updating dist every time is a drag, and it's not a sustainable way to handle a module like this in all likelihood. The way I've seen this work well for other projects is an unversioned build directory that works as the source for building, local development, and testing. dist is then only updated when a release occurs, at which point the contents from build are copied into dist, alongside all of the other things that need to happen during a release (version bumps in package.json and bower.json, git tags, publish to npm, copy changes in the docs into a release directory and push to gh-pages). dist is only updated once a release, and it's always the last commit of the release. This conveniently is also where the git tag is placed. All of this stuff is of course handled by a release task in Jake so you don't forget any of it.

If that's something you're at all interested in, I could try to figure it out in the picardy fork and PR . I'm kind of a build process nerd (though I admittedly have no Jake experience, I'm primarily a Grunt guy but I've written plugins and gotten in the weeds so I know what's up) and I really like Teoria. I can see Picardy using Teoria for a looooot of stuff and it would be a shame to always work downstream just because of the bower/npm thing.

[saebekassebil]

Hey @fastfrwrd, just wanted to hear if releasing this as a modular library has solved some of your problem? Now all code is require()'d instead of injected in a build process. This mean that you could now depend on the GitHub repo no?

[fastfrwrd]

It's definitely a great step! While it'll be a little tricky for us because we're on AMD and not CommonJS-style inclusion, there are ways around it. And, this makes it much easier to read and understand the source! Great work as always.

[saebekassebil]

I'm very glad to hear that it'll help you out. I guess there are some cool CommonJS-AMD transforms out there or something like that.

The code is still quite messy, but I'll be working to fix that

[saebekassebil]

It might interest you to know, that I've decided (anyway..) to include a UMD bundle of the module, per 2391e3f49c77f58fa4b0a6413facd5988a22c31f

I'll close this as a mixture of RESOLVED/WONT-FIX - Please let me know if you have any troubles using the bundle

[fastfrwrd]

Fantastic! We'll definitely make use of that. Cheers!