(Blocking) Problems of the js community and diverse package managers

48 views
Skip to first unread message

Philipp S

unread,
Aug 23, 2013, 7:30:45 AM8/23/13
to frontend-...@googlegroups.com
Hi guys,

I'm Philipp, web developer from germany. I invested a lot of research into package managers, dependency tools, build tools and deploy tools to get projects, focused on the backend (like php websites) to fluently work with frontend code (like js libraries, or frontend packages like bootstrap). Unfortnately I came to the same conclusion jordi came up in april 2012 (!). So the situation is not changed, yet.
Within my little research I found a lot discussions about the different package managers in the js community. They just can settle on anything. In a result of all this, everyone is building his own solution which isn't wide adopted. The jQuery project is starting to use its own package.json manifest file, bower has a really horrible registry (which is maintained by a single github issue), component(1) is forcing everyone to use common js modules, npm is to limited to node (and not browser libraries or modules). It's just getting worse over time.

I think the idea is really really great, but It will be very complicated to start the discussion.

Jordi Boggiano

unread,
Aug 23, 2013, 7:33:10 AM8/23/13
to frontend-...@googlegroups.com
I have to say I kind of gave up on the issue. We use bower + composer in
php projects with JS heavy frontends and it works ok-ish. It's not
perfect and doesn't allow requirements to cross the language boundaries,
but it's usually good enough.

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

Wil Moore

unread,
Aug 23, 2013, 2:37:27 PM8/23/13
to frontend-...@googlegroups.com
npm is to limited to node (and not browser libraries or modules). It's just getting worse over time.

 That's not true. The npm registry contains tons of front-end libraries. Check out browserify. Also, check out my comparison of some of the available tools: http://git.io/_ZWfVA

component(1) is forcing everyone to use common js modules

Well, that's true, but, why is that a problem? There are plenty of ways to run a development server with middleware that will process your assets (including CommonJS => Whatever) as you develop. Nothing is perfect but this workflow works quite well.

On the other hand, if you like AMD, you could try bower + RequireJS. The main nicety of RequireJS is that it allows loader plugins. We've built some for our project and it makes the bad parts of RequireJS a little nicer. Also, processing CommonJS => AMD is easy.

Reply all
Reply to author
Forward
0 new messages