Dual publish components to npm. about component HOT 50 CLOSED

I'd highly recommend rewriting your stuff. As you said yourself you're locked in a npm and browserify specific enviroment. This is an issue component tries to solve.

And updating - let's say - 15 modules to the new component spec is a work of rarely 20 minutes.
When you plan to dual publish our work you have to rewrite that too, so I don't understand why you won't tweak your models a bit.

from component.

@silvinci I'm not "locked in". I choose to use npm as my module management system.

When I say dual publish I mean I'll write a script to auto generate a package.json from a component.json then iterate over everything in component search and publish them all.

from component.

It would be very sad, if somebody converts the components to npm.

from component.

Maybe I should just ignore components and rewrite anything vaguely useful.

from component.

@Raynos Just out of curiosity: Why do you choose npm over component?

from component.

@enyo Probably because npm existed before component.

from component.

I will only personally continue publishing the ones I have been to npm for the next maybe month or so until we migrate over, though it's not super difficult to maintain both so I might just continue pushing to npm as well, we'll see, you're stuck with gross -component suffixes for npm though unfortunately (in most of the cases at least, some are fine, color-picker and a few were not taken)

from component.

not dual publishing leads to duplication of effort in the component repo and npm repo. which is a waste of effort / shame.

I'd personally use classes, event and matches selector if they were on npm.

heck I might rewrite classlist myself tonight and publish it to npm.

from component.

Classes is in npm, but sure if you want to rewrite them that's fine by me

from component.

Oh classes is. There were a bunch of other useful ones which are not in npm.

Seriously though. You write awesome code. I want to use it. It sucks I can't because of package manager differences.

from component.

That's one reason I prefer the gh namespace model, no collisions ever I don't have to name it classy classify classes-component haha, ya pkg managers suck :(

from component.

@visionmedia you have to name it something unique. But you never have to use it by that name. You can use the gh namespace.

And the only reason the gh namespace works is that every module is prefixed by the author's name by default.

Heck it doesn't solve the namespace issue at all. You are still forced to choose a unique name. Even worse you have no option to change your unique name. your stuck with visionmedia.

Namespacing is a problem, it is a pain, you've just moved it somewhere else.

from component.

You don't use usernames in code, just as deps, you still require tip or dialog etc

from component.

to me it's a pretty decent win using github:

• no extra credentials to maintain
• more stable
• faster
• name things whatever you want
• still require them as you would with npm
• immediately obvious where a package resides when you see it as a dep

from component.

That absolutely must go into the screencast in #37. Haha.

from component.

still require them as you would with npm

How does component handle loading visionmedia/markdown and isaacs/markdown. What does require("markdown") do.

from component.

First of all using two different packages that do the same doesn't seem smart to me.
Anyways you can require("visionmedia/markdown") as well. No name-collisions here.

from component.

@Raynos they're aliased to pseudo ./deps dirs, so one component requiring component/tip could require('tip'), and another could require foobar/tip in the same way. You couldn't use both in the same component, but if they're named the same it's 99% likely that you wouldn't want or need that anyway. I almost wish npm did it this way, could rid a lot of the stupid ambiguous names in there

from component.

@Raynos I needed the to use modules from everywhere as well, so I built this. It works for components, npm and browserify modules. Maybe it sucks, I don't know. I like it so far.

from component.

@stagas +1 if that's a solid solution then awesome.

from component.

I don't see why component solves the namespace-conflict-problem or why npm is a "lockin" into an evironment and component isnt.

You guys know, with npm you can do the following?

{ "name" : "foo"
, "version" : "0.0.0"
, "dependencies" : { "bla" : "https://github.com/userX/bla/tarball/v0.0.0" }
}

npm is all but a lockin! its a package-manager for packages we all agree to define in a specific way (node_modules -folder + package.json -file).

So for now at least, for me component is just noise :/ I really would like to see: what exactly are the benefits?

Please dont understand me wrong, I am a @visionmedia fanboy! But i dont see the real advantage of components over npm-packages. Why dont we just extend the package.json with {component:{files:[],styles:[]}} and write a fileserver which just mounts assets out of the node_modules -folder?

I heard that @isaacs said that he doesnt care about what exactly is in npm, so assets-only packages would be fine? As long as one does not care about naming-conventions (i.e. node_modules -folder + package.json -file).

Regarding the namespace-conflict, we dont have to use the registry as mentioned above. Component could be just a tool which greps a list of tarball-urls. But the important thing is, to make them a npm-package with a package.json file which will end in a node_module -folder after installation.

Maybe i am all wrong and dont get it at all, though i wanted to tell you guys my thoughts.

ps: in some way, component is to npm like coffeescript to javascript :p

from component.

@guybrush has a point.

There's no reason why component can't be a command line tool that uses npm as the repository instead of github.

Just have it auto publish component-visionmedia-classes or whatever have the the component tool abstract away the prefixes for you.

from component.

One of the key advantages of component is that it removes the need of an additional repository like npm, which has two main disadvantages:

1. The need for another account
2. Speed (It's faster to just download the few files needed of a component)

So having component autopublish to npm seems like a really bad idea.

from component.

Oh, and I think a really important argument in favour of component is that not only nodejs developers use browser components. So using something like component increases the chance of ruby, python, javascript, and, what the heck, even php developers share the same frontend components.

from component.

@guybrush +100, very well put. I don't get that as well, totally happy with npm.

from component.

@enyo sorry my english isnt good, but i think you didnt get the point i wanted to make.

npm isnt only about the npm-registry, you can define your dependencies with tarball-urls (also git-urls are possible besides using your own registry or multiple registries). so you dont have to rely on any registry what so ever. the important thing is how you define your packages.

that said, after looking into some components i noticed they are all built in that way (?):

component.json:

{ "name" : "foo"
, "version" : "0.0.0"
, "dependencies" : { "userX/bla" : "*" }
}

and an optional(?) package.json:

{ "name" : "foo-component" 
, "version" : "0.0.0"
, "dependencies" : { "bla-component" : "*" }
}

the problems i see with this:

• the package.json becomes an "odd" thing, instead of being an integral part and the most important thing regarding package-definition
• now i have to maintain 2 definitions for 2 ecosystems - which now introduces a real naming-problem, since i have 2 names for the same thing

how i think the whole problem would be solved "better":

• if you are not ok with the fact, that there can only be one module with a certain name in one registry, just dont put it into the npm-registry. host it anywhere and lets put a list online somewhere with tarball/git-urls
• send a PR to npm, which implements dependency-urls to packages where every file is served separate

so again, maybe i just dont get it - but imho components as of now do not only split the community but they create a seperate ecosystem instead of making the existing one better. i get it that clientside-modules/packages are not only about scripts but also include assets (sometimes even only assets). but i really would like to use them by installing them with npm!

also I think right now is a very important point in time, where we all decide how to do things in the future. and @visionmedia plays an important role in that decision since he is kind of an opinion-leader and actually implements his ideas instead of only talking about it. so for me.. if everyone sticks with the component-approach, i will have to also go this way :p

from component.

there's no advantage to using npm, I do not want to prefix / suffix everything either, sorry but npm is a no-go there's several advantages to not using npm and none for using it, other than the fact that node people already use it which is a pretty poor "advantage". Hell why not use gem(1) ?? let's just use brew?

from component.

@visionmedia you repeat that all over, without any constructive explanation, it's hard to treat you seriously.
I don't see any advantage for using components system, to me it's no value added just noise @guybrush explained the concerns very well

from component.

I dont feel the need to repeat my reasoning over and over, there's literally no advantage to using npm other than for node folks who feel that it already is important, any other ecosystem would say the same about their package manager. Component(1) is faster, has search that works, requires no secondary credentials like npm does to manage, solves the namespacing problem elegantly, private "registries" are as easy to set up as a file server. What does npm get you? nothing but ambiguity, hmm which packages are components, who knows, have fun filtering them all. People from other environments would complain about npm just as you're complaining about not using npm, it's no different than me forcing you to use gem(1). I like npm, I'm not bashing it or anything, it just makes very little sense to use for this sort of thing.

from component.

Component(1) is faster

NPM was never slow to me, so I don't see a problem you are trying to solve.

has search that works

NPM can be searched well and fast from various sources, its native search if it has problems, surely will have it solved

requires no secondary credentials like npm does to manage

The way NPM does is totally fine for me, why is that an issue for you?

solves the namespacing problem elegantly

Namespaces if needed can also be accomplished with npm, and technically if you want, you may just prefix any package you publish with any chosen string you want (some developers do that). Still public system shouldn't depend too much on namespaces, it makes it not clear. I don't favor namespacing on that public level.

What does npm get you? nothing

How constructive is that?

In my opinion it doesn't take much to turn npm into a decent package management also for client-side, it has great design and has already proved to work great for server-side. Creating other not compliant package systems introduces a mess, and moves us away from idea of one system that we can use across environments

from component.

this argument is not going anywhere, I'm not going to use npm sorry it makes no sense to me

from component.

I'll continue to publish some to npm with the ugly -component suffix, closing.

from component.

For what it's worth, I disagree with some of @visionmedia's arguments here, but not all of them.

The search capabilities in npm leave a lot to be desired, it's true. But it's also searching a much larger corpus of data, and is a much more challenging problem than what component has right now. That's not to say that I'm happy with npm having a shitty search experience, obviously; I'm not happy with it. In the meantime, if using some other system provides you with a better experience, then that's easily a short-term win. I'm skeptical that component will be able to avoid the same problems at the same scale that npm is today.

We've talked about namespaces, and that is a settled issue. I think that component will run into the problems that I've seen in other namespaced package lists. Maybe I'm wrong. Only experience will show us. I'm didn't judge that experiment to be worth the risk of the costs it would introduce; @visionmedia does. I'm grateful for that, and eager to see how it works out.

I don't think that picking a username and password is a big deal. Some kind of oauth to github would be nice, but it's also a non-trivial thing to implement, and it's not very high priority. Also, it would wed us to github in a way that would be very difficult to change in the future. You could argue that we're already wedded to github today, and that's a fair claim, but it wouldn't be hard to change when something better comes along. If we use github as the registry, or as a core part of the infrastructure, then we can't change that nearly as easily.

As I've said repeatedly in the past, I am perfectly happy with people using npm for non-node code. That's fine. I don't even think that the ambiguity is really as bad as you might expect, since it is all JavaScript, and a surprising amount of stuff is reusable (as browserify users have found). But I'm not willing to add features, complexity, or requirements for things that are not of benefit to the node user experience, because that is what I care about, and that is the core purpose of npm. If for whatever reason that means that npm is not a good fit for some use case, then using something other than npm is probably a very good choice. I think that comparing it to using gem is a bit weird, because it's a different language entirely. But I guess you could argue that css and html aren't javascript, so... I don't know.

Lastly, none of this is permanent. If @visionmedia wants to use github as the component registry, more power to him. If he gets to 10k packages and search starts falling over, and by that time, npm has fewer of the problems that he's unhappy with, then we can re-evaluate it. It's software. It's just costs and benefits. Component is a cool program, and it's great to see someone actually building something rather than just whine about stuff. That's why I have so much respect for @visionmedia, and take his criticisms seriously, even when I disagree with him. Let's see how this goes, and solve the problems that we encounter along the way :)

from component.

this argument is not going anywhere, I'm not going to use npm sorry it makes no sense to me

In case it wasn't clear, +1 to closing this thread. Better to be decisive than hesitant and democratic, especially with a thing that's as new as this.

from component.

I agree / understand that everyone would see it as a frustration as node users, and npm is great dont get me wrong I'm just coming at it from a different point of view, I'd like to make the thing as environment agnostic as possible. Right now of course the only implementation is using node anyway, but eventually if people like it they'd easily have "native" versions of component(1). There's almost no argument for or against npm, they're both convenient and inconvenient for different reasons. I wanted to even broader originally but my use of common-js kind of screws that over, lots of people will prefer AMD etc.. so for now I'm just building what I personally want in a dev environment, it wont be for everyone

from component.

for now I'm just building what I personally want in a dev environment, it wont be for everyone

That's pretty much the ideal approach, in my opinion. Don't waste time on imaginary users you don't have, when you are a real user today with a real need.

from component.

Thanks for explaining your thoughts in depth (again).

from component.

For what it's worth, at first I was opposed to the idea of component being something else and the whole repo story. I really don't know what's best, time will tell. But after actually using it for some time now, I must say I kinda dig it. Let me throw some bullets to tell you what I like:

• downloads are super fast, I mean, really.

• it downloads only the things that are actually used, not the whole repo/package, which means you need to explicitly declare every useful file (leaves little to wondering), bundling is also cheaper

• dep name is determined by the .json and not anything else. So I can fork component/foo, do something weird with it, change the dep to my username and it's still require('foo') to anything, so code doesn't need to be updated, (provided I kept the previous api).

  If I were to publish to npm, I had to change all requires to 'foo-with-my-feature' which is an extra annoying step and it's ugly. Recently npm allows you to point to a git url, but mainly I like the fact that github is the default and everything is there.

It mainly boils down to, it's using github which is really good, and it's the only choice, so if you want your shit in there, you need to put them in github. I don't want to seek in the entire internet to see a source code, fork something or submit an issue. This is a really good feature.

And of course, components are awesome! Use them now! Look at so many goodies you can component-install!

from component.

Guess I'm kinda late to this party (just found component a few days ago), but this is an interesting thread to read.

I encountered this when starting to write a component that could be used both in node and the browser.
Here is a gist with the way I solved this problem. Perhaps there is a better way to do this, but to me it seems like a very minor inconvenience for now.

I agree with @visionmedia and really like the approach that Component is taking. The only benefit I see to using NPM is for the small subset of component packages that are designed to work in Node as well. And in this case, it saves the author from having to dual publish. But this is a very minor inconvenience, and who doesn't push code to github before publishing to npm?

But sharing code between the node and the browser is an interesting topic.

I think browserify is definitely a cool and interesting approach - but it is a bit too heavy handed for me. For instance, packaging Resourceful using browserify results in like 150K of JS. No thanks.

I view the browser and node as two different execution environments.

Instead I much prefer the approach of things like superagent which provide a nice API and sane implementations for the specific environments. This is a package carefully designed to work in two places, so it makes sense that it is published to both registries.

Long story short - npm packages work in node, component packages work in the browser, makes sense to me.

from component.

yeah we're pretty screwed as far as things like emitter-component and emitter goes, Guillermo has been using a lot on the server/client as well and needs to do the same try/catch dance, no way around that with npm's namespacing really. I've had this issue with a few as well, set and set-component etc. The main problem with browserify IMO is that you really have to rely on polyfills, and even then there's a good chance what you're using wasn't designed for the browser and will have strange failures or edge-cases, or just a bad browser related API, I dont think that's the right way to go personally.

from component.

I think browserify is definitely a cool and interesting approach - but it is a bit too heavy handed for me. For instance, packaging Resourceful using browserify results in like 150K of JS. No thanks.

Only 10k of that is browserify the other 140k is just about how bloated resourceful is.

I view the browser and node as two different execution environments.

They are the same, they just have different host environments. Just like IE8 and chrome have different host environments. Simply write host environment agnostic code and your set.

from component.

@visionmedia have you considered just solving the namespace problem?

I.e.

require = require("require-no-namespace")

var Emitter = require('emitter')
    , querystring = require('query-string')

from component.

I dont think it's that simple personally, but if it's working for you go nuts! Nothing wrong with that

from component.

@visionmedia so I'm on the same page other then the namespace what other problems are there with npm?

from component.

i've mentioned them many times, I'm not discussing that part anymore. As for using them in npm yeah I guess you could have something like you mentioned, though you probably wouldn't want to call it require if you're mixing and matching require stuff with -component stuff

from component.

even if the only reason was simply that this project has nothing to do with node, that's enough of a reason for me

from component.

@visionmedia that means you cool with loading mocha through component in the browser and through npm in node?

I guess the "npm is a bad browser tool" is a bigger problem then "I'm using two tools for javascript stuff"

from component.

sure? that doesn't bother me at all, if it's a client-side project I'll use it in the browser, if it's node then I'll use mocha(1)

from component.

Then it's solving a different problem, makes sense.

from component.

I created a module which allows to require components from node programs as well as to easily share them with npm users.

https://github.com/eldargab/component-as-module

from component.