Как правильно скомпилировать TypeScript-проект?

photosho, tsc компилирует в js, а модули - надо чем-то еще обрабатывать, чтобы браузер мог их загрузить.
либо бандлером (вебпак самый популярный), либо попробовать нативные модули,
параметр "module" в "ES2015".

Гугл авторизация в expo(firebase)?

Denioo, видимо с этого и стоит начать.

Гугл авторизация в expo(firebase)?

нужны логи, настройки firebase, что возвращают вызовы функций, где ломается процесс, все такое.

Каким образом люди работают на русскоязчных биржах?

zorca, ну это только если с помощниками.

Как лучше всего написать сайт?

оэтому я и ищу хоть какую-то информацию, которая поможет как минимум начать, если есть что-то полезное буду очень рад это увидеть

Умники, которые будут кидать ссылки на обучение HTML/CSS/C# и т.д. , вы слишком преисполнены, чтобы отвечать на такой вопрос, поэтому не тратьте моё время)

вы уж определитесь.

Как правильно передать соединение с базой данных в модель?

VadimKholodilo, если от express не отказаться, а чего-то лучшего хочется, посмотрите на inversify и его интеграцию с express.

Что будет быстрее из следующего кода,и как вообще правильнее?

kirick kirick, по вашему примеру - второй вариант. В общем случае - когда как.

Как на JavaScript реализовать математически правильное округление?

Надим Закиров, лучше понять это раньше чем позже.

Какое внешнее лексическое окружение у анонимной функции, создаваемой при вызове другой функции в качестве ее аргумента?

В первом примере я создаю функцию прямо в методе then, когда передаю ее в качестве аргумента.

нет. ни в каком "then" вы ничего не создаете.

function a() {
  doSomething().then(() => {})
}

тут () => {} создается в функции a(). в then она потом (после создания) передается при выполнении, но контекст и лексическое окружение уже привязаны.

то, что эта функция создается в месте, куда передаются аргументы, никаким образом не влияет на ее внешнюю лексическую область видимости?

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

код выше в плане лексического окружения созданной функции полностью эквивалентен коду

function a() {
  const myFunc = () => {}
  doSomething().then(myFunc)
}

Как загрузить свой dataset в нейронную сеть?

зачем вы материтесь на человека так вот сразу.

Компилятор nodejs приложений?

GreyCat9515, задача babel - это компилировать js в js.
nodejs и то как оно будет работать когда вы все это запустите - к бабелю не имеет отношения.
плагины в бабеле - это не то же самое что "плагины в ядре работающего приложения", общего между ними только слово "плагины".

Если вам надо плагины в вашем приложении (чтобы ядро при запуске могло загружать модули) - делайте это руками или ищите библиотеку которая позволяет добавить функционал плагины в ваш код.

Если под "расширить возможности js" вы подразумеваете предыдущий пункт, то никакие компиляторы, бабели-вебпаки вам не нужны.

Если вы под этим подразумеваете что-то другое - опишите внятно, что именно.

Тестовое задание на Junior Frontend, не кидалово?

ну еще некоторые ждут что их ответы отметят как решение, если они помогли

Компилятор nodejs приложений?

Собираю систему модулей. Модули находятся в отдельной директории. При запуске программы ядро инициализирует все модули. Ядро заранее ничего не знает о модулях, ресолв производится в рантайме.

это все решается на уровне require(). Хоть при запуске, хоть динамически в процессе работы. Хоть "все что там лежит в этой папке". Даже "а не положили ли чего еще в эту папку" каждую минуту в процессе работы ядра.

я не понимаю зачем вам тут вебпак, бабель, какие-то бандлы, что-то от чего-то отдельно компилировать?

задача которую вы описали решается так:
- делаем папку для модулей.
- ядро при запуске читает эту папку, делает require для каждого файла.
- модули имеют какой-то стандартный апи, ядро через это апи инициализирует каждый модуль.

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

Как итог, добавляя новый модуль в директорию ядро должно нормально определить его. Следовательно модули нужно компилировать отдельно от ядра

Не важно как вы компилируете модули, в рантайме вы подключаете js-файлы, отуда они взялись не имеет значения, они запускаются и работают. Если пишете на TS, компилируете tsc получаете js файлы, их уже загружаете. Если пишете на JS с использованием фич которые ваша версия ноды не поддерживает - используете бабель чтобы перевести код в то что поддерживается. В любом случае - у вас в итоге папка с js файлами, которые грузятся в ноду через require и все.

для nodejs вообще в принципе не надо делать какие-то бандлы. Единственное в чем может быть полезен вебпак в этом случае - это если вы хотите сделать hot reload в процессе разработки. Но там будет много заморочек.

Если честно, впечатление что у вас не очень ясное понимание как оно все устроено, и вы решаете проблему которую наполовину придумали.

Стоит ли отправлять ответы по веб сокету, если соединение уже установлено или лучше использовать rest?

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

А так как вы поставили вопрос - "А есть ли смысл утруждаться, если можно совместить рест + сокеты". Смысл есть, почему - я ответил.

Функция валидации которая выбрасывает исключения?

alex4answ, чаще всего применяется именно так, особенно в тестах, но ничего не мешает использовать этот же подход в продакшен коде, если у вас обработка ошибок построена на исключениях.
Кидать исключения - это нормально, особенно для библиотек. Например apollo делает именно так. https://www.apollographql.com/docs/apollo-server/d...

Опять же не всегда это хорошо подходит, например в случае валидации данных лучше провалидировать все сразу и собрать ошибки, как вам тут писали. Но как по мне, дружелюбную к пользователю валидацию лучше делать на UI, а на стороне сервера чаще всего можно и на первой ошибке возвращать.

конкретно с модулем Assert в ноде есть такое неудобство что он будет кидать AssertionError, а принято кидать исключения разного типа чтобы можно было поймать нужную ошибку. В других языках есть поддержка этого в самом языке, то есть конкретный catch будет работать например на AuthorizationError, и не будет на другие, в js такого нет, но практика разных типов исключений тоже широко используется.

assert я привел как пример использования этого подхода. Можно писать свои функции, как вы привели в примере. Главное называть понятно, canDoSomething обычно предполагает возврат true/false. А assertSomething - более стандартное название для функции которая гарантирует что для дальнейшего кода какое-то условие будет выполнено. можно назвать ensureSomething или еще как-то подходящим образом.

Как узнать какие числа из массива являются фибоначчи?

Rsa97, как это поможет если надо проверить например 29837239080394820901928309443948572938477498123798234791827 ?

Как сделат localstorgate на http https?

Если вы не знаете как оно там все устроено и работает то тут точно никто не знает.
смотрите настройки, разбирайтесь.

Что я не правильно делаю в тестовом задании?

DarkOracleLex, на граничных условиях проверили? Ограничения по памяти? нашли пример где не работает? или вы хотите чтоб вам кто-то ваш код разобрал, протестировал и нашел ошибку?

Что я не правильно делаю в тестовом задании?

проблема то в чем у вас?

Стоит ли отправлять ответы по веб сокету, если соединение уже установлено или лучше использовать rest?

ivan0512, вы хотите добавить в систему еще один протокол, заметно усложняя ее просто чтобы не "утруждаться". то что этот протокол простой понятный и не надо думать чтобы его прикрутить не меняет дела.
Это можно сделать если у вас аврал, и дедлайн сорван на месяц, чтобы заткнуть дырки и спокойно подумать потом.

В нормальном состоянии лучше сразу немного подумать над тем как сделать систему лучше и проще, чем лепить ее из тех решений что удобно прикрутить прямо сейчас. Потому что через год - два такой работы у вас будет динозавр, который будет состоять из кучи "легких" решений, костылей чтобы их между собой соеденить и такой-то матери.

Если вы хорошо обдумали, и знаете как добавить поддержку запрос-ответа в сокеты, и видите что это решение будет сложней и хуже чем прикручивание реста, тогда да, можно прикручивать рест. но тут никак не может быть аргументом "ну, нам для этого надо напрячься и подумать".