-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
package naming and file placing #1
Comments
I just cloned my currently being used libraries which uses js.node as Regarding the macro I’m not sure if it is cool because users could want to Just guessing. 2015-11-10 0:41 GMT-02:00 Dan Korostelev notifications@github.com:
[image: Imagem inline 1] |
I vote for using js.npm vs js.node for the npm externs. Regarding managing all the externs: I have whole bunch I would like to commit somewhere. Having separate repositories for each individual extern is way too much work for me, there are simply too many, and some of them are a couple of small externs. I would like at least one repo that is fairly loosely controlled that contains most externs and is updated often since externs do not change all that much. Then for specific externs that require versioning, they can use some other mechanism. Perhaps a macro solution could be used that could version the externs? By default use the latest, but have some ability to specify older versions. |
Obviously I'd vote for About extern "mess", the variable quality is pretty much that of the npm public repo itself. This being said, I believe it might be cleaner to always have |
a single js.npm is fine for me. I think they should all be in the same repository. Even if that's harder to manage for us, it's much more easy for end users to use. If it's a single extern class we can have it in a single .hx directly in js.npm. If it's a more complete API creating a package seems necessary. We should however define a format to deal with version requirements, for instance the users can use -D npm-mysql=1.5 and the code can check #if (npm_mysql >= 1.5) ... |
PS: @clemos solution works for me as well |
Okay, we agreed on the Do we want to just Pros:
Cons:
The bit about different using versions could be solved by what @clemos suggests (using OTOH we could go the DefinitelyTyped way and just provide a repo with externs for users to simply add Pros:
Cons:
What I'm thinking about is a bit more complex solution that gives us both from two worlds:
[
{
name: "express", // this is name of the top library dir
version: "1.0", // this is version that we're compatible with
depends: ["cookie", /* etc... */] // other externs we want to add to classpaths along with this
classpath: "src",
test: "test.hxml" // this can be used by travis to build/run tests for a lib
},
{
// etc...
}
]
Pros:
Cons:
|
@nadako Also, about |
That is an interesting idea for the haxelib! cc @back2dos Unfortunately, the example such as mongoose one you mentioned is quite common in nodejs world, for example the popular Let's (for now) keep it simple and just use a single source root following the hxnodejs packaging convention (like in haxe-js-kit) and hear more opinions on this meanwhile. |
I think too, that a single package name is better for now. js.npm.a.b.c should be treated as only js.npm.a
|
I'd like to propose that npm might be a better place than haxelib to
distribute haxe code that is npm specific. Maybe it's just a crazy idea. I
haven't thought through the technical details, but I think down the line it
will probably make for a more natural workflow.
As for putting everything into one repo: I think it won't scale. It just
feels wrong that the way to get mkdirp externs is by installing express and
react and what not along with it. If (as Nicolas said) having separate
repos is less hard to manage, then there's nothing in the way of having
separate repos and then just one hxnodelibs haxelib that adds the rest as
dependencies (or do that with npm).
The main reason for keeping these different projects separate is
versioning. What if there's a new major release of express? Will hxnodelibs
adapt and screw everyone who can't upgrade? Or will it stick to the older
version and be useless to all those who want to switch to the new version?
I'm pretty certain that after the io.js merge we're in for quite a few
major releases in the next year or two.
|
These are very valid points. I personally have nothing against multiple-repo scenario, since I really would like to properly support my externs with examples and travis compile-testing. One thing I'm not sure whether it should be done using HaxeFoundation github account, maybe a separate one would be better. |
Maybe a HaxeNodeFoundation :D Doesn't Git have a submodules feature? But I liked the idea of maybe creating another account or organization to 2015-11-10 14:43 GMT-02:00 Dan Korostelev notifications@github.com:
[image: Imagem inline 1] |
I've made an example extern lib for the popular |
@nadako |
Yep, that's nice. Personally, I think it's ok if the facade is at the same level as the package. Short names are good ;) |
Does anyone have any concrete ideas on how versioning could work? @back2dos Your idea has a lot of good points. In fact, what if we included the Haxe externs in the actual module itself, not as a separate npm module? If we submit git pull requests to the library owners, I'm pretty sure most would be ok with it, even if they don't know about Haxe, since we can justify it (it helps me use your library in a better way) and then the versioning of the extern would be lock step with the actual npm module. E.g. we can suggest that in an npm module, if there is a 'haxe' directory, we use that as the src directory, so scan the ./node_modules folder at compile time, or include them in the build.hxml. Having separate repos for more complex externs makes sense, but there are an awful lot that are very simple and writing tests for those simple ones is likely not going to happen. |
Also, even though we are still figuring things out, would pull requests for simple externs be accepted? I'd like to start centralizing my externs in a single place, and regardless on our eventual decision, at least all the externs would be in one place. |
Now when hxnodejs is finally released, we can discuss a bit about this extern collection.
I don't like how it's currently done here using
js.node
as a prefix package since it may introduce conflicts with core node modules added at some time, also I don't like the fact that one can't easily say which is node API and which is a npm module.@clemos uses
js.npm
prefix which I think is better, but I don't quite like that different externs (of different quaility and by different authors) are placed in one root - it gets messy when there are lots of them, IMO.I wonder if we can/should use separate source paths for different npm externs and somehow still be able to just do
-lib hxnodelibs
and then simplyimport js.npm.Whatever
. Maybe with macro that adds class paths and is executed inextraParams.hxml
?That way extern authors can also provide README's, tests, examples, etc.
Thoughts? @clemos @ncannasse @andyli @dionjwa @fponticelli @eduardo-costa @tong @back2dos (please cc anyone i forgot)
The text was updated successfully, but these errors were encountered: