external и globals в сборке sapper client с использованием rollup

Сборка с использованием rollup поддерживает внешние и глобальные переменные.

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

Если мы дадим ему global, он «установит» этот результат импорта в global в umd bundle.

Но если сделать то же самое при использовании модуля sapperkeeps в качестве внешнего, тогда сборка сервера работает нормально, но сборка клиента не учитывает глобальные переменные, а пытается выполнить `` импорт '' в браузере и не работает с TypeError,

': Не удалось разрешить спецификатор модуля «…»'.

Можно ли сохранить библиотеку как внешнюю в sapper клиентской сборке и указать ей использовать глобальную библиотеку вместо импорта? Или я здесь ошибаюсь в некоторых фундаментальных принципах?


person damodarreddy challa    schedule 30.11.2019    source источник


Ответы (1)


Когда вы сохраняете модуль, внешний по отношению к пакету, на самом деле это означает, что объявление import сохраняется в сгенерированном коде. Итак, если у вас есть что-то вроде

import foo from 'foo';

тогда код вашего сервера будет иметь что-то вроде

const foo = require('foo');

(который работает из-за алгоритма разрешения модуля Node), и в вашем клиентском JS вы получите точно такой же _4 _... который не работает в браузерах, потому что пути импорта должны быть относительным. (Это может измениться в будущем с импортом карт.)

Самое простое решение - не использовать external, а просто позволить Rollup справиться с этим (вы можете сделать это только для клиента). Но если вы действительно хотите использовать вместо этого глобальный, вы могли бы использовать _6 _ :

plugins: [
  virtual({
    foo: `export default window.foo`
  }),
  // ...
]

а затем добавьте тег <script> в свой src/template.html, который указывает на файл в static.

person Rich Harris    schedule 30.11.2019