как красиво сделать импорт для таких штук, как изменить такой экспорт

export default {
 x:{
   y: {
     d: ..
    }
  }
}

что бы можно было например сделать

import d from "..."

что бы не делать такого

import x from "..."
var d = x.y.d;

?

cyber,
сделай обёртку для такого объекта

destus, в каком смысле обертку? геттеры?

cyber,
а как модуль-фабрика в CommonJS нельзя сделать?

destus, не я перехожу полностью на es6 import/export. webpack 2 развалил совместимость между, module.exports и import. так же они поломали https://github.com/59naga/babel-plug...module-exports

cyber,
а через геттер, не устраивает? Или

let obj = {
	x: {
		y: {
			d: ...
		}
	}
}

export {obj, obj.x.y.d} ...

т.е. в любом случае где-то надо явно обратиться к свойству d, чтобы получить ссылку.

Раздельный экспорт?

//a.js
export const d = {};
export const y = {d};
export const x = {y};

//b.js
import {d} from a;
import {y} from a;
import {x} from a;

assert(x.y == y);
assert(x.y.d == d);

Какой самостоятельный роутер сейчас самый модный?)

Привет, сейчас в проекте использую. Пока использую как LocalStrategy. Как тебе этот middleware? Что интересного почитать, кроме доки и хабра?

Erolast,
как одно из решений, которое я нашел

как избавится в ноде от путей типа ../../../utils/index в require ?

собственно grunt править не пришлось
вариант решения здесь
http://javascript.ru/forum/node-js-i...irektorii.html

https://www.npmjs.com/package/findup-sync и похожие модули, но похеришь автокомплит в IDE.

Не надо, поверь. Ничего плохого в них нет, а вот если их убирать и заменять какими-нибудь конструкторами путей -- путаницы и неудобств будет куча.

пример из реального кода :|

../../../../../../../../../../../../../utils/index

Ну порядок поиска вроде как в документации описан. Можно и переменную окружения NODE_PATH настроить соответствующим образом.

destus, да, я знаю, как работает require,в NODE_PATH тоже много не запишешь, просто спрашивал, кто как решает эту проблему

cyber,
в node_modules можно закинуть :)

Боюсь, это уже с архитектурой проблемы.

Хотя, в общем-то, мне бы всё равно было пофиг на такую строку.

знаю, пытаюсь это как то исправить

Таки дошли руки до перехода с JSCS на ESLint (по причине мерджа JSCS в ESLint и закрытия проекта) - полёт нормальный, всё пока гуд, но на настройку конфига ушёл не один час)

В связи с чем? Они же обещали не ломать совместимость правил.

Это был просто маркетинг, совместимости нет :D

Хм, то ли мне память отказывает, то ли текст поменялся :)
(Отсюда)

Крч, нескоро, подозреваю, переползу на еслинт.

Скачал посмотреть из любопытства. Пока не очень обнадеживает. Лично я особого performance boost на Ubuntu 16.04 не заметил, скорее наоборот.

Несколько вопросов к тем, кто разрабатывает на Node.js:
1) какую БД вы используете?
2) почему именно эту БД?
3) какие модули (ORM?) для работы с этой БД?

nerv_,
mongoose. А для кого статистику собираешь?

1. MongoDB
3. Mongoose
2. Я нуб и не понимаю в чем разница между этими вашими БД, так что использую первую попавшуюся :)

nerv_, эм, так от задачи же зависит. Где-то Редис, где-то Монга, где-то мускул. Если говорить о том, что лучше знаю -- Монгу, наверное. Без монгуза, убогий он.

Всем спасибо за ответы :)

исключительно для себя

знаю, что от задачи зависит, но, зачастую, задачу можно поставить по другому, упростить и т.п., словом, подогнать под те инстурменты, которыми владеешь

Хочешь сказать под все эти БД пишешь нативно + много SQL руками?
Я, например, сейчас демку делаю mysql + camintejs. Приятная ORM, но много в ней нет, той же связи Many-to-Many.

Много SQL не пишу, поймал) Так как нет нужды. А под монгу ORM использовать бессмысленно, имхо. Там и без него просто, особенно с async functions. Для валидации -- JSON Schema. И даже если припрёт использовать -- то точно не монгуз, у него схема отстой.

Про редис -- ну тем более, он же тупо key-value, очень шустрое.

kobezzza, что там с декораторами решили? Их оставят в стандарте или нет?

Там всё зависло, думаю оставят, но войдут в стандарт году в 18-19.

Взяли и максимуса опять забанили.
Нормально же себя вел)

Erolast,
так у него же пожизненный бан, нечего было язык распускать.

Будь любезен, покажи пример валидации. Желательно, чтобы еще файлы валидировать можно было :)

Вопрос ко всем: какие модули исопльзуете для валидации на Node.js?

Для koa я нашел следующие:
https://github.com/nswbmw/koa-router-schema
https://github.com/Jackong/koa-input
https://github.com/RocksonZeta/koa-validate
https://github.com/nswbmw/koa-scheme
https://github.com/koajs/parameter

Теперь задача определится, какой использовать :)

Я юзаю https://github.com/hapijs/joi

Схему целиком скидывать не буду, но как-то так:

{
  "id" : "/inventory#",
  "properties": {
    "_id": {
      "type": "string",
      "format": "ObjectID"
    },
    "slug": {
      "type": "string",
      "pattern": "^[0-9a-zA-Z-_]+$"
    },
    "uuid": {
      "type": "string",
      "format": "uuid"
    },
    "condition": {
      "type": "object",
      "properties": {
        "cityIds": {
          "type": "array",
          "items": {
            "type": "integer",
            "minimum": 0
          },
          "minItems": 1,
          "uniqueItems": true
        }
      },
      "additionalProperties": false
    },
    "where": {
      "type": "object",
      "properties": {
        "offset": {
          "type": "integer",
          "minimum": 0
        },
        "screenName": {
          "type": "string",
          "default": "main"
        }
      },
      "additionalProperties": false
    }
  }
}

Хранить файлы в БД? Это не ко мне.

Кстати, для небольших случаев валидации я тоже использую joi -- всё-таки полноценные схемы заморочно писать, а в joi всё быстро и понятно. Плюс он валидирует не JSON-объект, а JS-объект (т. е. там можно и наличие ф-ции проверить, например).

kobezzza, спасибо :)

Где ты это прочитал?)
за схему спасибо

Ну, я говорю, что использую для валидации данных в монге json-схему. Ты просишь показать пример валидации, желательно, чтобы файлы тоже можно было валидировать. Я делаю из этого вывод, что ты хранишь файлы в бд)

Да было б за что :) Таких примеров можно сотни накопать. JSON -- он JSON и есть, не суть, кладешь ты его в монгу или на файловую систему. Я понимаю, зачем нужны ORM для релях -- там представление данных другое, и его в любом случае приходится мапить, а ORM позволяет это руками не делать, а вот для монги, имхо, она нафиг не уперлась. Да, там есть пара пакостных мест, типа преобразований ObjectID из строки в бинарный тип, но в остальном...

Если решишь юзать json-схему для валидации -- бери ajv, она самая шустрая и прокачанная.