2011/1/4 Kris Zyp <kzyp at dojotoolkit.org>:
To install packages, you can download the CPM package manager from:
http://github.com/kriszyp/cpm
This is awesome, thanks Kris for putting the work into this! This is
the kind of approach I was hoping for in a package manager. Some
questions and comments:

1) I installed the "has" package, and it's "main" config mentions
"main":"./has.js", but I thought the "main" value was a module name,
and not a .js file. I was looking at this page before and its "main"
example:
http://wiki.commonjs.org/wiki/Packages/1.1

What has been your practical experience with "main" values? RequireJS
assumes it is a module name at the moment.

2) For normal RequireJS projects, I am going for a design where the
user only specifies one script tag for the page, that looks like:
<script type="text/javascript" data-main="path/to/main.js"
src="path/to/require.js"></script>

where main.js is the top level script for the page, and it has its
require([]) call to start up the app. When I had thought about package
config before I was thinking I would just inject it at the top of the
main.js file, instead of having a nested require() call to load
packages then load the page. I liked that it reduced the first
blocking request on packages.js before doing the main app loading, but
it does have the downside of some config blob at the top of the user's
main JS file.

However it works out I was hoping for something that would not have
the nested require() boilerplate. Not sure how best to do this though,
still feeling it out. Which leads to the next item...

3) I keep wondering if CommonJS packages are really a good idea. I
don't like the variability that the config for lib and main provide.
It seems to lean towards configuration over convention. I would be
open to entertaining a world where a package is just a directory and
to get the main module, you always ask explicitly for it, so
require("packageName/main") vs require("packageName").

It would mean that a package manager may need to massage existing
CommonJS-based packages though. I'm also not sure how much people want
to avoid typing "/main" for each top level package entry point, or if
package authors are OK with their scripts being at the top level of
the package. But I am really not a fan of all the config junk, and its
cost in a loader. I know you brought up a similar concern before about
loader cost for it, just wondering if you thought more about it.

4) You had talked about leveraging work done by npm: did you mean just
using the same protocol, or more? Would it be possible to use the
registry used by npm with cpm? How do you see those two things working
together?

5) It seems like it would be helpful if RequireJS created a
package.json, I'll look into doing that.

6) Along the lines of a RequireJS package: ideally I would want to
deliver a much smaller package for use by end users. There is lots of
stuff in tests, docs and build that are really not useful for people
who just want to use require.js and its plugins. Any thought on how to
do that via GitHub or some alternate cpm/cpr config? I normally just
tag the master for a release. Maybe I would need to create some
branches that had reduced file contents for each release?

Thanks again, this looks really neat!

James

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 4 | next ›
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedJan 4, '11 at 10:38a
activeJan 12, '11 at 9:27p
posts4
users2
websitedojotoolkit.org

2 users in discussion

Kris Zyp: 3 posts James Burke: 1 post

People

Translate

site design / logo © 2022 Grokbase