Is this library still being maintained?

[sir-dunxalot]

Is this library still being maintained? https://github.com/sir-dunxalot/ember-tooltips uses this library and I'd like to continue doing so. However, there are some issues blocking use for some developers. For example, #24 and class namespacing (sir-dunxalot/ember-tooltips#15).

[darsain]

At the moment I have a lot of other things on my plate, but I definitely want to continue working on this library. I want to finish this and parent darsain/tooltips lib that depends on it.

The main issues why my projects seem abandoned atm is kinda not having that much free time as I used to, but mainly because I just don't see a good, comfortable and standardized front-end library publishing method that I'd want to work with.

If you closely look at features and development workflow of all available package management solutions, you arrive at conclusion that npm sux, browserify sux, webpack sux, jspm sux, bower sux^2. The only good thing in this ecosystem that covers 99% front end needs and is nice and easy to use is duo (successor to component), but none is using it, so your stuff wont get consumed in an ideal way, and you can't consume popular libs because they don't support duo, and you have to resort to manual duct taping with vendor folders.

This is such a demotivating factor. Every time I get some time and enthusiasm to work on my projects, I realize, oh yeah, front-end PM sux, none will be able to use that, nevermind... And I really don't want to be publishing whole built standalone versions (what your ember-tooltips is using). It's such a sub-optimal way how to consume my libraries. You end up with tons of duplicated code and larger build files. I originally intended them to be used only for replicating issues on jsfiddle etc. but because of the state of affairs it became the main method how people include my stuff in their code bases.

I even have several awesome projects that have been sitting on my HDD for more than half a year now, unpublished, because there's just nowhere good to publish them to... (again, duo is good, but none is using it, so it's not good; catch 22...) fuck.

If you ask what are my requirements for front-end package manager, it's simple. Allow me to build front end stuff. That means:

Separete JS and CSS asset aware build pipelines. So JS, CSS, images, fonts, SVG, JSON, whatever front-end files (duo already has that, with nice and simple API). This is in all of the currently popular solutions only an after thought. They all care mostly only about JS, and any CSS, or god forbid asset aware solution is just sub-optimal hacky shit held together by duct tape,... and horrible to work with. Just looking at webpack config file makes me feel like a goatse cameraman.

It pains me to ignore all issues being opened or discussed on my projects, but the situation described above just steals all the motivation from me.

Sorry, got carried away.

[darsain]

There is a little hope in this project: https://github.com/makojs/core

It'll probably go unnoticed and unused, cause front-end development is most of the times not a meritocracy, but a popularity contest.

[sir-dunxalot]

Thanks for the lengthy response - I feel your pain. I've not worked with this kind of package before but I'm willing to try and get some PRs up at some point if that's useful? If so, maybe you could provide some dev instructions like anything special for the local environment, how to run tests, what command to build the package with, etc.

Also, I've found NPM modules with Browserify to be a decent distribution and consumption pattern.

[darsain]

I'm willing to try and get some PRs up at some point if that's useful?

Don't. The main problem here is the lack of a good package manager & builder. No PR is gonna fix that. The currently opened issues are easy to implement when that will get resolved. But there is not many things on the horizon suggesting that's gonna happen.

And I don't want to work on this in its current state and lock myself even further into the duo ecosystem when none is using it and thus able to consume packages in this form.

Also, I've found NPM modules with Browserify to be a decent distribution and consumption pattern.

Last time I checked, browserify had a lot of issues (which is why webpack was created? not sure) and didn't had a sane solution for packages to distribute CSS files and other assets, and consumers to build them. I think there are some plugins that don't work very well. Basically, in all currently popular package managers, everything except JS is a second class citizen, so you can't use them to distribute libraries like this one which comes with CSS. And library with images and/or fonts would be even bigger nightmare.

NPM does seem like an inevitable destination for my stuff, but we still need to wait for some competent npm package consumer and builder for front-end like makojs linked above is striving to be.

[benzkji]

any thoughts, 4 years later? I agree on webpack config files, but it looks like it became the standard?