Cleaning Further
gilles coomans
So, thx Kris for all those recents jobs...
Maybe we could go a little bit further... ;)
1) the status of those libs needs to be clarified :
- Transporter (which use require.paths that is no more present in node
0.6.x, and use Nodules as loader in the examples)
- CommonJS-utils, which is not any more used by wiki-example
- it could be great to publish the last version (0.2.2) to npm
registry
(for the moment I've copied js code in my index.js to break
dependencies)
- Nodules : which also use require.paths, and is not anymore used in
Installation Tutorial.
- I love the rapidity and convenience of hot reloading feature of
Nodule, and I believe that's a real plus for developpement purpose.
Event if it's not usable in conjonction of heroku facilities, for
local dev, it's a must.
So what's up for them ? Any plan?
2) To have the wiki example working out of the box on heroku or
locally with npm1.0.105/node0.6.x :
2.a ) it needs more dependencies in package.json of wiki root. i.e. :
"dependencies": {
"pintura": ">=0.3.0",
"templify": ">=0.9",
"jsgi-node": ">=0.2.5",
"perstore": ">=0.3.0",
"promised-io": ">=0.3.0",
"requirejs": ">=1.0.0",
"rql": ">=0.3.1",
"tunguska": ">=0.3.0",
"wiky": ">=0.95.1",
"websocket-server": ">=1.4.04"
}
2.b) For heroku target : there is something boring whith
require("pintura/start-node").start; function.
Heroku provides the server port dynamicaly , and so it's not possible
to know it before reading the node's process.env.PORT.
Pintura.pintura.start(...) uses the PORT from the
perstore.util.settings (which reads the local.json).
(pintura.start-node.js/start : line 10).
And so : heroku complains.
So to avoid modification on pintura now (which is loaded by npm) :
I've copied the start function (from pintura/start-node.js) in the
index.js (of wiki), and take the process.env.PORT as port.
Maybe we could find a cleaner solution.
2.c) A last thing, is that the repl process (which is called in start-
node.js and index.js) don't seems to work and crash the heroku app.
I've commented out the lines.
Now, I've the wiki running out of the box :
- locally (npm 1.0.106/nodes0.6.3)
- on heroku with default runtime environnement (npm1.0.105/node0.4.7)
- on heroku with custom runtime environnement (npm1.0.105/node0.6.1)
G.
Gilles Coomans
Kris Zyp
> Hi all,
>
> So, thx Kris for all those recents jobs...
> Maybe we could go a little bit further... ;)
>
> 1) the status of those libs needs to be clarified :
>
> - Transporter (which use require.paths that is no more present in node
> 0.6.x, and use Nodules as loader in the examples)
inconvenience of making modules that can work in AMD and CommonJS,
Transporter doesn't seem to be terribly valuable anymore. I thought it
would be better just to use raw files in AMD format for modules that
will go to the client.
>
> - CommonJS-utils, which is not any more used by wiki-example
> - it could be great to publish the last version (0.2.2) to npm
> registry
> (for the moment I've copied js code in my index.js to break
> dependencies)
Unfortunately someone else published commonjs-utils in npm, so I can't
update it. After realizing this, I looked through commonjs-utils and it
seemed most stuff could be reasonably reorganized into other packages
and I could simplify/reduce the number of packages.
>
> - Nodules : which also use require.paths, and is not anymore used in
> Installation Tutorial.
> - I love the rapidity and convenience of hot reloading feature of
> Nodule, and I believe that's a real plus for developpement purpose.
> Event if it's not usable in conjonction of heroku facilities, for
> local dev, it's a must.
>
> So what's up for them ? Any plan?
Yes, that is definitely important. I was thinking of looking into
separating out just the reload functionality from nodules. However, I
was wonder if this would provide significantly better functionality than
other options like node-supervisor.
>
>
> 2) To have the wiki example working out of the box on heroku or
> locally with npm1.0.105/node0.6.x :
>
> 2.a ) it needs more dependencies in package.json of wiki root. i.e. :
> "dependencies": {
> "pintura": ">=0.3.0",
> "templify": ">=0.9",
> "jsgi-node": ">=0.2.5",
> "perstore": ">=0.3.0",
> "promised-io": ">=0.3.0",
> "requirejs": ">=1.0.0",
> "rql": ">=0.3.1",
> "tunguska": ">=0.3.0",
> "wiky": ">=0.95.1",
> "websocket-server": ">=1.4.04"
> }
I am curious why these extra dependencies are needed? The wiki doesn't
directly use templify and jsgi-node, does it? Why is not enough to have
these as transitive dependencies of pintura?
>
> 2.b) For heroku target : there is something boring whith
> require("pintura/start-node").start; function.
> Heroku provides the server port dynamicaly , and so it's not possible
> to know it before reading the node's process.env.PORT.
> Pintura.pintura.start(...) uses the PORT from the
> perstore.util.settings (which reads the local.json).
> (pintura.start-node.js/start : line 10).
> And so : heroku complains.
>
> So to avoid modification on pintura now (which is loaded by npm) :
> I've copied the start function (from pintura/start-node.js) in the
> index.js (of wiki), and take the process.env.PORT as port.
>
> Maybe we could find a cleaner solution.
I wouldn't mind having start-node.js check process.env.PORT. We could do
this on line 10:
var port = settings.port || process.env.PORT || 8080;
Would that help?
>
> 2.c) A last thing, is that the repl process (which is called in start-
> node.js and index.js) don't seems to work and crash the heroku app.
> I've commented out the lines.
I'll add a check for settings.repl before turning on the repl so you can
set "repl": false in your local.json to turn it off.
BTW, I would love to see more information on how to setup Persevere on
Heroku. In particular, how did you setup the DB?
Thanks,
Kris
gilles coomans
> > 2) To have the wiki example working out of the box on heroku or
> > locally with npm1.0.105/node0.6.x :
>
> > 2.a ) it needs more dependencies in package.json of wiki root. i.e. :
> > "dependencies": {
> > "pintura": ">=0.3.0",
> > "templify": ">=0.9",
> > "jsgi-node": ">=0.2.5",
> > "perstore": ">=0.3.0",
> > "promised-io": ">=0.3.0",
> > "requirejs": ">=1.0.0",
> > "rql": ">=0.3.1",
> > "tunguska": ">=0.3.0",
> > "wiky": ">=0.95.1",
> > "websocket-server": ">=1.4.04"
> > }
>
> I am curious why these extra dependencies are needed? The wiki doesn't
> directly use templify and jsgi-node, does it? Why is not enough to have
> these as transitive dependencies of pintura?
>
- jsgi-node is used in my index.js because I've copied the start-
node.start function which uses it.
I would be unnecessary now (i.e. with pintura start function
modifications)
- templify is there beacause I need it in my own demo, and I prefer
that npm place it in the root node_modules (not in node_modules/
pintura/node_modules/...) for access convinience
>
> I wouldn't mind having start-node.js check process.env.PORT. We could do
> this on line 10:
> var port = settings.port || process.env.PORT || 8080;
> Would that help?
>
Definitively yes. Thx.
>
>
> > 2.c) A last thing, is that the repl process (which is called in start-
> > node.js and index.js) don't seems to work and crash the heroku app.
> > I've commented out the lines.
>
> I'll add a check for settings.repl before turning on the repl so you can
> set "repl": false in your local.json to turn it off.
>
> BTW, I would love to see more information on how to setup Persevere on
> Heroku. In particular, how did you setup the DB?
For the moment I used JavascriptDB, as in wiki example. So I do not
manage db connections. But I plan to connect to a mongoHQ instance
really soon. I'll see there what's needed.
Thx for everythings... ;)
+