Packages/1.1 tire kick
Mikeal Rogers
and it has been updated by Kris Kowal based on various discussions.
The current proposal is at
http://wiki.commonjs.org/wiki/Packages/1.1
There is a lot of refinement and a bunch of properties were made
optional rather than required.
Rather than arguing about the finer points of features that aren't
actually even addressed in this spec yet (mappings, version
comparisons, etc) I'd like to further refine what we *have* defined,
put it up for a vote, and replace the current version which is highly
out of date.
This version of the spec definitely won't be final but it's an
improvement over 1.0 and removes the required surface area of a
package.json file which should increase adoption. After this version
is finished we can continue arguing about the finer points of features
that we might slate for 1.2.
In addition to what's been done I think we can make the following
properties optional:
-description
-licenses
-maintainers
And I think we should also add the "main" property and make it required.
Which would leave only name, version and main as required.
The reason I think we can remove this surface area is because it's not
required under any circumstances for package installation. Most other
attributes are only required for package repositories and some
packages won't ever be uploaded to a repository but they *should* have
a way that they can be installed with a package manager from a zip or
tarball or directory tree. We need to encourage the creation of
package.json first and foremost, package repositories are going to
have their own list of required attributes anyway and we shouldn't
allow those requirements to increase the minimum surface area of the
spec.
-Mikeal
Kris Kowal
> In addition to what's been done I think we can make the following
> properties optional:
>
> -description
> -licenses
> -maintainers
+1
> And I think we should also add the "main" property and make it required.
+1 to adding it, specifying that it's a path relative to the package root.
I recommend rather than being required, that the existence of the property
indicates that a main file exists. It does not make sense for every package
to have a main. At the very least, it remains disputable in the context of
the features we're discussing elsewhere.
> The reason I think we can remove this surface area is because it's not
> required under any circumstances for package installation. Most other
> attributes are only required for package repositories and some
> packages won't ever be uploaded to a repository but they *should* have
> a way that they can be installed with a package manager from a zip or
> tarball or directory tree. We need to encourage the creation of
> package.json first and foremost, package repositories are going to
> have their own list of required attributes anyway and we shouldn't
> allow those requirements to increase the minimum surface area of the
> spec.
Sounds good to me overall.
Kris Kowal
Mikeal Rogers
>
> +1 to adding it, specifying that it's a path relative to the package root.
> I recommend rather than being required, that the existence of the property
> indicates that a main file exists. It does not make sense for every package
> to have a main. At the very least, it remains disputable in the context of
> the features we're discussing elsewhere.
How about "relative to the package.json file"?
Also, if there isn't a main, and there isn't a lib directory, what is
imported when you do require("name")? If we are trying to specify the
minimum set for package installation I think we at least need to know
what is imported after installation.
-Mikeal
Kris Kowal
> How about "relative to the package.json file"?
Yeah, that's good.
> Also, if there isn't a main, and there isn't a lib directory, what is
> imported when you do require("name")? If we are trying to specify the
> minimum set for package installation I think we at least need to know
> what is imported after installation.
If the package.json for the "foo" package does not mention a "main",
require('foo") should throw an error. Assuming that in a future
discussion we resolve that submodules are addressable like
require("foo/bar") (which I presently support), there will be cases
where a package provides a suite of utility modules without having a
main, and this should be discoverable from package.json. I maintain
that using the "main" module as the exclusive point of linkage would
strike the wrong balance.
Kris Kowal
Mikeal Rogers
do think that in a future version of the spec, once we work out the
submodule semantics, that either "main" *or* "lib" must be included
for it to be a valid package.json file.
-Mikeal
> --
> You received this message because you are subscribed to the Google Groups "CommonJS" group.
> To post to this group, send email to comm...@googlegroups.com.
> To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
>
>
Kris Kowal
> In the interest of moving forward I'm +1 on making it optional but I
> do think that in a future version of the spec, once we work out the
> submodule semantics, that either "main" *or* "lib" must be included
> for it to be a valid package.json file.
Okay. I personally am ready to +1 a rev, whenever it's ready for a
show of hands. Thanks for the kick.
Kris Kowal
Isaac Schlueter
I'd suggest that we specify that either "main" or "lib" must be specified.
Also, should "main" be a module reference or a relative path? The
only difference is whether or not there's a .js on the end, but I
could imagine an env like couchdb where you have no physical files,
but you do have modules. Currently, npm treats it as a module
reference, but I can strip off the (.js|.node)$ easily enough.
--i
Kris Kowal
> I'd suggest that we specify that either "main" or "lib" must be specified.
I won't argue about this since you and Mikael are putting your feet
down; I'll still be +1. However, I do like Narwhal's approach of
convention before configuration on the lib directory and we'll
certainly continue to support it. It would not hurt my feelings if the
specification were stronger than necessary, especially if it makes
other implementors' lives easier, or liberates them from the
convention.
> Also, should "main" be a module reference or a relative path? The
> only difference is whether or not there's a .js on the end, but I
> could imagine an env like couchdb where you have no physical files,
> but you do have modules. Currently, npm treats it as a module
> reference, but I can strip off the (.js|.node)$ easily enough.
The other difference is that "main" as a path would be relative to
package.json rather than the lib/ directory.
Still +1
Kris Kowal