Hi all
most modules have an entry point, which is by default index.js.
But what if my module does not have one entry point?
What if it is a colleciton of many small cross-project core utility modules
that i would not always want to load them all to use one of them?
I mean, by doing
var core = r
I found this thread while looking for the reason why the "directories.lib"
was dropped a couple years ago
(reason: https://groups.google.com/d/topic/nodejs/hAoPAPz4J1k/discussion).
While
Izaacs have some pretty good points I still want this feature into node
core... Other CommonJS environments
require("kitchen-sink/lib/foo");
You can already require files.
On Thu, Jan 17, 2013 at 10:09 AM, wrote:
> PS: I do NOT want to start a discussion about keeping everything as
> separate packages, I really want a "kitchen sink" for this case. I'm not
> the first one to want this feature and I pr
I know that, to quote my previous e-mail:
> The issue is not about the extra 4 chars ("lib/") but about having
different require paths depending on the environment, code will be less
portable.
I don't want `require("kitchen-sink/lib/foo")` on one environment and
`require("kitchen-sink/foo")`
On Fri, Jan 18, 2013 at 3:19 AM, wrote:
> I don't want `require("kitchen-sink/lib/foo")` on one environment and
> `require("kitchen-sink/foo")` on another, the lack of a "directories.lib"
> setting is hurting compatibility/flexibility. It's a shame to have to follow
> the less flexible system jus
can ringo not require("kitchen-sink/lib/foo") ?
You could just move your files to the root of your folder. If there are too
many files then don't have so many files.
On Fri, Jan 18, 2013 at 3:19 AM, wrote:
> I know that, to quote my previous e-mail:
>
>
> > The issue is not about the extra 4
On Fri, Jan 18, 2013 at 7:34 PM, Jake Verbaten wrote:
> You could just move your files to the root of your folder. If there are too
> many files then don't have so many files.
This. Exactly this.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mai
I don't know if you guys are just trolling or think that I'm dumb (maybe
both?). EVERYONE knows that you can use the full path or put the files at
the root folder - both are far from being "optimal" as described on
previous emails. It's not because you can do some silly hack that the
problem doesn'
Magically finding files in a /lib directory sounds scary. Maybe I missed it,
why not be explicit with your requires if you're including multiple files in
your module? (not commenting on if I think this is a good idea)
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com
Check out utile: https://github.com/flatiron/utile
It has helpers requireDir and requireDirLazy which scan for .js files and
exposes an object for each file with the key being the filename.
On Fri, Jan 18, 2013 at 10:27 PM, Luke Arduini wrote:
> Magically finding files in a /lib directory sound
On Friday, January 18, 2013 9:42:10 PM UTC-7, Isaac Schlueter wrote:
>
> On Fri, Jan 18, 2013 at 7:34 PM, Jake Verbaten
> >
> wrote:
> > You could just move your files to the root of your folder. If there are
> too
> > many files then don't have so many files.
>
> This. Exactly this.
>
Y
On Sun, Jan 20, 2013 at 1:36 AM, Austin William Wright
wrote:
> You cannot make the assumption that that's the one correct way to do things.
> Even if you can't think of a reason that someone would want to stuff their
> files in a subdirectory, that's no reason at all to not allow it.
Node and np
On Monday, January 21, 2013 7:46:01 PM UTC-7, Isaac Schlueter wrote:
> Who's a wall? You can either put your files in the root of your
> package, or you can put "lib/" or whatever in your require() function
> calls. You're saying that you want to add complexity to Node that *no
> one else wan
On Tue, Jan 22, 2013 at 7:00 PM, Austin William Wright
wrote:
> On the contrary, what sort of project could Node.js be if everyone actually
> cared about doing things the objectively correct way.
"Objectively correct"? Wow.
Node programs run on filesystems. Every step of indirection away from
On Wednesday, January 23, 2013 1:13:47 AM UTC-7, Isaac Schlueter wrote:
>
> On Tue, Jan 22, 2013 at 7:00 PM, Austin William Wright
> > wrote:
> > On the contrary, what sort of project could Node.js be if everyone
> actually
> > cared about doing things the objectively correct way.
>
> "Object
>
> Other costs, like how require("foo/bar") can be
either foo/bar, or foo/bar.js, or foo/bar/index.js, are simply
> historical mistakes that seemed like a good idea at the time, but
> provide no value, and are now too costly to remove.
Is `index.js` considered a non-preferred method of doing pa
On Wed, Jan 23, 2013 at 9:13 AM, Jacob Groundwater wrote:
> Is `index.js` considered a non-preferred method of doing package imports? I
> really like it, but arguing a stable feature is pointless. I'm just curious
> what the reasons were for including it, and what has changed since?
>
> FOR SCIENC
> index.js predates packages by quite a long time. It was the first
> "load a packagey folder thing as if it was a single module" feature,
> dating back to the 0.1.x days. It's not terrible. But personally I
> prefer a main script in package.json, since you can name it something
> more appropria
On Wednesday, January 23, 2013 11:34:17 AM UTC-7, Isaac Schlueter wrote:
>
> On Wed, Jan 23, 2013 at 9:13 AM, Jacob Groundwater
> >
> wrote:
> > Is `index.js` considered a non-preferred method of doing package
> imports? I
> > really like it, but arguing a stable feature is pointless. I'm ju
On Wed, Jan 23, 2013 at 7:30 PM, Austin William Wright
wrote:
> ...
Look, here's the bottom: The module system is locked. We're not
interested in changing it. The source is open, so you can go nuts on
it if you'd like. Your feelings about node's module system are rare,
and not shared by the de
Since it's still being discussed...
## To give some context
I'm all favor of small modules that does one thing and does it well,
"single responsibility" is usually my mantra except when it doesn't.
Almost all my open source projects have a single responsibility:
- http://millermedeiros.github.
I'm also getting confused, but still I'm after simplicity and rather happy
that 'directories' are not supported any more.
Isaac do you see any semantics in 'lib' folder? Do you feel that some
modules should rather be placed in 'lib' than at 'root' fo the package (or
other way) or it's totally "
On Wednesday, January 23, 2013 9:04:52 PM UTC-7, Isaac Schlueter wrote:
>
> On Wed, Jan 23, 2013 at 7:30 PM, Austin William Wright
> > wrote:
> > ...
>
> Look, here's the bottom: The module system is locked. We're not
> interested in changing it. The source is open, so you can go nuts on
>
tl;dr
Skimming over this thread I don't see anyone jumping on listas'/austin's
bandwagon. I, for one, certainly agree with Isaac's arguments. I also
think he has been very nice in putting in so much effort in replying to
such a stupid concern.
In short, +1 for Isaac's arguments.
On Thu, Jan 2
>> We don't destabilize node-core for vocal minorities.
> Absolutely not: If something is wrong, you change it and increment the major
> version number. That's not "destabilizing" in any sense of the word, that's
> improving functionality, and telling people that you broke reverse
> compatibility i
On Thursday, January 24, 2013 12:57:13 PM UTC-7, Isaac Schlueter wrote:
>
> You're about 2 years too late, Austin.
>
> We only break reverse-compatibility when absolutely necessary, and
> never for modules that are marked with the "Stable" stability level or
> higher.
> There are some act
On Thursday, January 24, 2013 11:51:47 AM UTC-7, Mark Hahn wrote:
>
> tl;dr
>
> Skimming over this thread I don't see anyone jumping on listas'/austin's
> bandwagon. I, for one, certainly agree with Isaac's arguments. I also
> think he has been very nice in putting in so much effort in replyi
On Jan 24, 2013, at January 24, 20131:03 PM, Austin William Wright
wrote:
> Node.js has broken reverse compatibility three times on me, and not in a
> minor version update, during a *patch* update.
What broke, and in which versions? I'm not aware of compatibility changes in
minor versions si
If it was in an unstable version, then that is by design. That's where we
make API changes. But, we still try to minimize them, even there.
On Thursday, January 24, 2013, Mikeal Rogers wrote:
>
> On Jan 24, 2013, at January 24, 20131:03 PM, Austin William Wright <
> diamondma...@users.sourceforge
oh yeah, 0.odd are all unstable and subject to change. for the most part they
shouldn't be targeted by developers.
On Jan 24, 2013, at January 24, 20131:39 PM, Isaac Schlueter
wrote:
> If it was in an unstable version, then that is by design. That's where we
> make API changes. But, we still
I'll have to dig up exactly when it was, but the most recent incident was
unfortunately with crypto, in the middle of the v0.6 series, when behavior
of 'binary' changed. Nothing serious, but it locked me out of my
application, and (theoretically) reduced the security of my tokens by about
a doz
On 1/24/13 5:57 PM, "Isaac Schlueter" wrote:
>>> We don't destabilize node-core for vocal minorities.
>> Absolutely not: If something is wrong, you change it and increment the
>>major
>> version number. That's not "destabilizing" in any sense of the word,
>>that's
>> improving functionality, and
I believe there is no performance drop if you require a huge library and
only use a small part of it. I mean, code memory is a small part of the
total memory you use.
danmilon.
On 08/13/2012 01:02 PM, Osher E wrote:
Hi all
most modules have an entry point, which is by default index.js.
But
You can use getters like connect does.
https://github.com/senchalabs/connect/blob/master/lib/connect.js#L86-92
2012/8/13 Osher E :
> Hi all
>
> most modules have an entry point, which is by default index.js.
>
> But what if my module does not have one entry point?
> What if it is a colleciton o
here, I'm looking at:
http://wiki.commonjs.org/wiki/Packages/1.1
Specifically - search for "directories", and you'll end up with these texts:
- directories.lib - directory of modules to be loaded under the packages
namespace. *require(name/subfilename)* must return modules from this
here, I'm looking at:
http://wiki.commonjs.org/wiki/Packages/1.1
Specifically - search for "directories", and you'll end up with the
following findings in the texts, all of them under the section
Package Descriptor File
- directories.lib - directory of modules to be loaded under the
each module should to just one thing. if it does a lot of things it
should really be separate modules.
On Fri, Aug 17, 2012 at 5:01 PM, Osher E wrote:
> here, I'm looking at:
> http://wiki.commonjs.org/wiki/Packages/1.1
>
> Specifically - search for "directories", and you'll end up with the
That's really great in theory.
In fact, you confuse between a module and a package.
Try to claim that underscore does only one thing. It does not - it gathers
helpers for many different problems.
Underscore has one entry point that loads everything, and because of that -
you can find other versio
sorry for the jabber - but I have to add to my previous mail - that it's a
little more then just declaring what OO programmers would recognize as
public and private ...modules in a package.
Technically, one can cheat, and do
*var **logger* = *require*(*"./node_modules/my-org-core/lib/logger"*);
a
> I believe there should be a way to do the same, but without coupling with
the folder structure.
well that it about convention over configuration. if you follow the folder
structure, you dont have to change or configure anything in 95%-99% of
cases. thats how it works in many javaEE libs and s
40 matches
Mail list logo
