Символические ссылки файловой системы? Какая ОС, софт или жесткие ссылки? какие изменения можно сделать репо с воспроизведением?

Операционная система Windows. Создана символическая ссылка с использованием опции "npm link" на внешний модуль. Если модуль установлен, то проблем нет. Но для локального тестирования нам нужно создать символические ссылки, а это работает не только с плагином typescript2. С плагином typescript1 символические ссылки работают, но перечисления не работают.

Та же проблема, но я использую lerna для связывания пакетов, а накопительный пакет жалуется на неожиданный токен для связанных пакетов.

точно такая же проблема с окнами с lerna
Если я копирую папку прямо в node_modules, все в порядке, но с символической ссылкой не работает

@PavaniVaka @TerenceZ @thealjey есть ли шанс на небольшое репо с воспроизведением?

@ezolenko Простите, нет. Но я немного сузил вопрос. Я заметил, что если внешний модуль копируется в каталог приложения, он работает. Но если это просто символическая ссылка, тогда она не работает. Например: с yalc мы можем легко проверить внешние зависимости. Потому что он создает папку yalc в каталоге приложения и копирует внешний модуль в эту папку, а затем создает символическую ссылку из папки yalc на node_modules. Надеюсь, это даст ключ к разгадке.

@ezolenko Я действительно понял, в чем проблема в моем случае, и это не имеет ничего общего с этим плагином (он отлично работает) или символическими ссылками в этом отношении.
Это скорее недостаток самого машинописного текста, а точнее его конфигурации, основанной на файлах json.
Проблема заключалась в том, что символическая ссылка разрешала файл вне CWD.
Я просто переместил свою команду сборки в файл package.json верхнего уровня, и все начало работать.

я думаю, что мы здесь на одной странице.

194

@PavaniVaka @TerenceZ @thealjey есть ли шанс на небольшое репо с воспроизведением?

@ezolenko https://github.com/moki/mokui есть один.

Я решил проблему №194, на случай, если кто-то столкнется с такой же проблемой, ниже я предлагаю решение:

Когда кто-то пытается собрать каждый отдельный пакет внутри монорепозитория, накопительный пакет пытается разрешить @organization/package-name и включить его в сборку. Вы этого не хотите, поэтому, чтобы избежать этого при создании каждого пакета, я разбираю package.json , извлекаю ключи поля dependencies , а затем проверяю их внутри callback one может предоставить поле external внутри сводной конфигурации. Это даст желаемый результат.

import json from "rollup-plugin-json";

const pkg = process.env.LERNA_PACKAGE_NAME &&
          require(`${process.env.LERNA_PACKAGE_NAME}/package.json`);

const dependencies = ({ dependencies }) => Object.keys(dependencies || {});

const pkgdependencies = dependencies(pkg);

/* exported rollup configuration */
const config = {
    /* your config goes here... */
    /* id is the source name if list of dependencies includes
     * id source name, then mark it as external,
     */
    external: id => pkgdependencies.includes(id)
};

export default config;

та же проблема и rollup-plugin-typescript работает

Проблема также возникает, когда файл в src является символической ссылкой на файл машинописного текста вне проекта.

например, файловая структура, как показано ниже:

core/core-client/src/api.ts
myapp/myapp-client/src/api.ts
myapp/myapp-app/src/domain/api.ts -> ../../../myapp-client/src/domain/api.ts
myapp/myapp-app/src/domain/core -> ../../../../core/core-client/src/domain/
...

когда я компилирую проект в myapp / myapp-app,
сводная жалоба с ошибкой ниже:

[ ERROR ]  Rollup: Parse Error: ../myapp-client/src/domain/api.ts:28:7
           Unexpected token (Note that you need plugins to import files that are not JavaScript)

     L28:  export interface IPrimus extends Primus {

со словом interface выделенным красным

Мое обходное решение - использовать pre / post hook в скрипте npm, чтобы разъединить и связать файлы ...
Таким образом, моя IDE может проверять наличие последней версии во время разработки и может компилироваться при сборке.