webpack & использование узловых модулей в изоморфном пакете - PullRequest
0 голосов
/ 20 января 2019

Я создаю изоморфный пакет, в котором я использую флаг в различных файлах, чтобы определить, находимся ли мы в браузере или в узле. Если в узле, мне требуется внутренний пакет, то есть if (isNode) { require("/.nodeStuff) }, который имеет в качестве одной из своих зависимостей модуль fs. Однако веб-пакету это не нравится по понятным причинам. Существует ли какой-либо тип конфигурационного файла на основе модуля, который я могу настроить, чтобы полностью игнорировать требования на основе узла, чтобы этого не произошло?

1 Ответ

0 голосов
/ 20 января 2019

Первый вариант

Как указано в документации, для решения этой изоморфной проблемы вы можете просто запустить две сборки, по одной для каждой среды (узла и сети).Руководство можно найти здесь .Имейте в виду, что вы, вероятно, должны высмеивать любые встроенные модули в clientConfig, добавив этот блок node: { fs: 'empty',//any other node lib used }.Таким образом, webpack не будет жаловаться, и, поскольку ваш клиентский код будет находиться в состоянии !IS_NODE, пустой fs никогда не будет использоваться.

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

Второй способ

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

// webpack.config.js

{
    mode: "development",
    entry: './index.js',
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: '[name].js'
    },
    node: false
}
// nodeStuff.js

const fs = __non_webpack_require__('fs'); //this will be transformed to require('fs')

fs.writeFileSync('some','thing)

Таким образом, поскольку nodeStuff.js потребуется только при условии IS_NODE, будет доступен собственный require.

Я бы предложил использовать __non_webpack_require__ только для нативных библиотек, и вы уверены, что они будут доступны!

...