digitalmars.D - I can't use nodejs anymore. Please vibe.d, don't follow that path
- Karabuta (75/75) Oct 20 2016 This is actually a nodejs project's dependencies for a small
- Chris Wright (8/11) Oct 20 2016 Nothing prevents you from doing the same types of things with D. However...
- =?UTF-8?Q?S=c3=b6nke_Ludwig?= (10/15) Oct 21 2016 I personally always try to minimize external dependencies, because at
- Karabuta (7/28) Oct 22 2016 The thing about nodejs web frameworks is the usually lack of some
- Kagamin (3/6) Oct 21 2016 Maybe it will be enough to declare some "batteries 2.0" package
This is actually a nodejs project's dependencies for a small
code-base.
{
"name": "Houston",
"version": "0.3.0",
"description": "Backend for AppHub",
"main": "build/houston/index.js",
"dependencies": {
"babel-core": "^6.9.1",
"babel-loader": "^6.2.5",
"babel-plugin-syntax-async-functions": "^6.8.0",
"babel-plugin-syntax-export-extensions": "^6.8.0",
"babel-plugin-transform-export-extensions": "^6.8.0",
"babel-plugin-transform-regenerator": "^6.9.0",
"babel-polyfill": "^6.9.1",
"babel-preset-es2015": "^6.9.0",
"babel-register": "^6.9.0",
"bluebird": "^3.4.0",
"co": "^4.6.0",
"css-loader": "^0.25.0",
"debug": "^2.2.0",
"del": "^2.2.0",
"dockerode": "^2.2.10",
"gulp-babel": "6.0.0",
"gulp-postcss": "^6.2.0",
"gulp-webpack": "^1.5.0",
"gulp": "3.9.0",
"ini": "^1.3.4",
"jade": "^1.11.0",
"jsonwebtoken": "^7.1.9",
"koa-convert": "^1.2.0",
"koa-passport": "^2.1.0",
"koa-router": "^7.0.1",
"koa-session": "^3.3.1",
"koa-static": "^3.0.0",
"koa-views": "^4.1.0",
"koa": "^2.0.0",
"lodash": "^4.13.1",
"moment": "^2.15.1",
"mongoose": "^4.4.19",
"monq": "^0.3.4",
"nodegit": "^0.14.1",
"nunjucks": "^2.4.2",
"passport-github": "^1.1.0",
"pluralize": "^1.2.1",
"postcss-cssnext": "^2.8.0",
"postcss-loader": "^0.13.0",
"raven": "^0.12.1",
"raw-body": "^2.1.6",
"semver": "^5.1.0",
"socket.io-client": "^1.4.6",
"socket.io": "^1.4.6",
"style-loader": "^0.13.1",
"superagent": "^2.0.0",
"syslogd": "^1.1.2",
"webpack": "^2.1.0-beta.20"
},
"devDependencies": {
"ava": "^0.16.0",
"babel-eslint": "^6.1.2",
"babel-plugin-webpack-alias": "^2.1.1",
"eslint-config-a-standard": "^1.0.6",
"eslint-config-standard": "^6.0.1",
"eslint-plugin-ava": "^3.0.0",
"eslint-plugin-babel": "^3.3.0",
"eslint-plugin-promise": ">=1.0.8",
"eslint-plugin-standard": ">=1.3.1",
"eslint": "^3.6.0",
"mock-require": "^1.2.1",
"nock": "^7.7.2",
"stylelint": "^7.4.2"
},
Dependencies upon dependencies. Each package comes along with its
own dependencies. I give up nodejs, you win. Now I am investing
my time in Vibe.d which I hope ...
Oct 20 2016
Chris Wright <dhasenan gmail.com> On Thu, 20 Oct 2016 20:25:40 +0000, Karabuta wrote:Dependencies upon dependencies. Each package comes along with its own dependencies. I give up nodejs, you win. Now I am investing my time in Vibe.d which I hope ...Nothing prevents you from doing the same types of things with D. However, dub lets you have subpackages, so there's less reason to have hugely granular packages. You can publish a `babel` package for people to use instead of having each downstream consumer list out nine different dependencies within the project. In your example, that would cut down probably 10-15 dependencies, but you'd still have about 25 left.
Oct 20 2016
Am 20.10.2016 um 22:25 schrieb Karabuta:This is actually a nodejs project's dependencies for a small code-base. (...) Dependencies upon dependencies. Each package comes along with its own dependencies. I give up nodejs, you win. Now I am investing my time in Vibe.d which I hope ...I personally always try to minimize external dependencies, because at some point they always cause problems. Sometimes it's possible to resolve those quickly, but even then, it usually leaves a bad taste if they are required for the whole system to function reliably. On the other hand, my plan is definitely to split vibe.d itself up into separate libraries, so that they can be maintained and versioned according to their individual development pace. But that means just that they are in separate repositories instead of submodules within the same one, not finer granularity.
Oct 21 2016
On Friday, 21 October 2016 at 11:14:41 UTC, Sönke Ludwig wrote:Am 20.10.2016 um 22:25 schrieb Karabuta:The thing about nodejs web frameworks is the usually lack of some basic functionality you would expect from say PHP without external libs. Little/single packages are more trouble, each with its own API design convention. Makes maintenance tedious. When one package dies out of support, problem comes: you have to find something else (which involves making huge code changes).This is actually a nodejs project's dependencies for a small code-base. (...) Dependencies upon dependencies. Each package comes along with its own dependencies. I give up nodejs, you win. Now I am investing my time in Vibe.d which I hope ...I personally always try to minimize external dependencies, because at some point they always cause problems. Sometimes it's possible to resolve those quickly, but even then, it usually leaves a bad taste if they are required for the whole system to function reliably. On the other hand, my plan is definitely to split vibe.d itself up into separate libraries, so that they can be maintained and versioned according to their individual development pace. But that means just that they are in separate repositories instead of submodules within the same one, not finer granularity.
Oct 22 2016
On Thursday, 20 October 2016 at 20:25:40 UTC, Karabuta wrote:Dependencies upon dependencies. Each package comes along with its own dependencies. I give up nodejs, you win. Now I am investing my time in Vibe.d which I hope ...Maybe it will be enough to declare some "batteries 2.0" package and depend on it?
Oct 21 2016