Нам все еще нужно приложить все усилия для прекомпиляции пакетов для NPM? - PullRequest
Новая
       68

Нам все еще нужно приложить все усилия для прекомпиляции пакетов для NPM?

0 голосов
/ 26 марта 2020

В настоящее время я работаю над проектом, в котором будет много пакетов для npm. Я хочу принять более радикальный подход к этому проекту. Таким образом, файлы не должны быть предварительно скомпилированы. В папках пакетов sr c будут только файлы d.ts, ts, js, m js (как я уже сказал, ни один из них не должен быть предварительно скомпилирован). Я делаю это из-за лени и потому, что я думаю, что время прекратить предварительную компиляцию файлов!

Я имею в виду, сколько вариантов я должен создать? ESModules, AMD, Common Js, System JS?

Моя простая мысль: оставьте все как есть (импортируйте x из 'x', export foo = 123) и разработчика, который использует пакет уже будет иметь правильный инструмент (Babel, Typescript)! или нет?

Второй вопрос: до какого уровня должен компилироваться пакет? ES3, ES6? Что делают пользователи пакетов, которые используют только современные браузеры и поддерживают только их? дифференциальная нагрузка будет правильным подходом здесь? Я видел только дифференциальную загрузку в среде HTML файлов. Так что в качестве отправной точки! Это не тот случай, если разработчики используют пакеты выборочно.

В частности, у меня вопрос: нужно ли нам все-таки прилагать все эти усилия? Какой на данный момент самый низкий общий знаменатель? Я не знаю статистических чисел, но у меня такое ощущение, что все используют компилятор / препроцессор (Babel, Post Css) в своем проекте?

Что вы думаете об этом?

1 Ответ

1 голос
/ 26 марта 2020

По моему опыту, модули Common JS и ES являются современными технологиями. Возможно, вы решите пропустить Common JS, тогда вы будете жить без транспиляции. Однако многие фреймворки и другие библиотеки по-прежнему используют Common JS, и они не могут использовать модули ES.

В качестве упрощенного подхода вы можете сделать следующее:

First : написать все как модули ES по умолчанию и выложить пакет для использования в качестве модулей ES по умолчанию (например, установить "type":"module" в вашем пакете. json и использовать .mjs в качестве файла окончание).

Затем : Используйте Babel, но только для создания общего JS запасного варианта ваших модулей. Это может выглядеть так:

Добавьте следующие зависимости dev в ваш проект. (Существуют другие плагины Babel для особых случаев синтаксиса; обычно Babel скажет вам, какие из них нужны): 

npm install --save-dev @babel/cli @babel/core @babel/plugin-syntax-import-meta @babel/plugin-transform-modules-commonjs

Затем добавьте следующий блок в ваш пакет. json: 

"babel": {
    "plugins": [
        [ "@babel/plugin-transform-modules-commonjs" ],
        [ "@babel/plugin-syntax-import-meta" ]
    ]
}

Теперь вы можете перенести свои модули ES в Common JS с помощью простой строки кода оболочки: 

# assuming your ES modules are in the lib/ directory
for script in $(find lib/ -iname '*.mjs' | grep -v test.mjs | sed -e 's|.mjs||g'); do
    npx babel $script.mjs > $script.cjs
done

Вы также можете добавить это как скрипт в ваш пакет. json. 

"scripts": {
    "build": "for script in $(find lib/ -iname '*.mjs' | grep -v test.mjs | sed -e 's|.mjs||g'); do npx babel $script.mjs > $script.cjs; done"
}

Теперь вы можете запустить это с npm run build, добавить его в качестве ловушки фиксации или запустить его перед отправкой в ​​реестр NPM. Вы также можете создать папку, отличную от той, в которой находятся ваши модули ES, и исключить эту папку с помощью .gitignore.

Так я создал несколько своих библиотек (по тем же причинам), и они отлично работают - как в Common JS, так и в средах с модулями ES.

Кстати, NodeJS содержит некоторую документацию по отгрузочным пакетам как для модулей ES, так и для Common JS: https://nodejs.org/api/esm.html#esm_dual_commonjs_es_module_packages

...