Используйте все файлы в папке, как один большой JS - PullRequest
Новая
       18

Используйте все файлы в папке, как один большой JS

7 голосов
/ 16 июня 2019

Можно ли настроить ESLint в WebStorm, чтобы функции, переменные и т. Д. Анализировались также из файлов в той же папке?В процессе сборки я объединяю все файлы в тех же папках в большие замыкания, например: 

   src/
      main/          ===> "main.js"
          api.js
          init.js
          ui.js
          constants.js
          .
          .
      renderer/      ===> "renderer.js"
          core.js
          events.js

Я бы хотел, чтобы ESLint обрабатывал все эти файлы как один, так что я не получаю "undef""ошибки для вещей, которые определены.

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

EDIT : Почему я не (не могу) использовать модули?TLDR - устаревший код и требования проекта.

  • Мне нужно минимизировать весь код.Текущий компилятор замыкания может переносить ES6 в ES5, но я обнаружил, что некоторые функции ES6 очень склонны к созданию неработающего кода.Поэтому я вынужден использовать ES5.

  • Как мне нужно ES5.Я мог бы использовать только require() для использования модулей.Это проблема, так как require () - это динамическое включение, которое влияет на производительность в моем контексте (приложение для больших электронов для устройств с умеренным питанием)

Итак, чтобы ответить @Avin_Kavish, я согласен с тем, чтоЯ делаю это «технически не соответствует», но в конце процесса сборки это так, потому что каждая папка была сгруппирована в файл.Этот файл является модулем или сценарием.Для группировки файлов я использую плагин Gradle https://github.com/eriwen/gradle-js-plugin, Я вставляю «заголовок закрытия» и «нижний колонтитул закрытия», и все файлы между ними в нужном мне порядке.

Несмотря на неудобства, в конце я получаю суперкомпактный код nodeJS, со всеми запутанными методами и т. д.

В итоге я воспользовался предложением @Patrick, спасибо за это!

РЕДАКТИРОВАТЬ 2

WebPack + Electron-WebPack оказался тем, что я искал.

Кстати, я думаю, что правильный способ сделать это, если EsLint разрешит "папка" sourceType.

Ответы [ 2 ]

4 голосов
/ 16 июня 2019

Вы не предоставили примеры кода в своем вопросе, но я предполагаю, что вы делаете что-то вроде этого:

api.js 

const api = {
  fetchData() {
    // some code that fetches data
  }
};

core.js 

const core = {
  init() {
    api.fetchData();
  }
};

Правило ESLint, которое вызывает ошибки при линтировании этих модулей JavaScript, - это правило no-undef .

Проверяет переменныекоторые используются без определения.В приведенном выше примере кода core.js это будет api, поскольку он определен в другом модуле, о котором ESLint не знает.

Вам все равноэти ошибки, потому что в вашем фактическом JS-пакете, используемом в рабочей среде, код из api.js и core.js объединяется в один пакет, поэтому будет определен api.

Так что на самом деле api в этом примере является глобальной переменной.

Правило no-undef позволяет вам определять глобальные переменные, чтобы они не вызывали ошибок.

Есть два способа сделать это:

Использование комментариев

В начале модуля core.js добавьте эту строку: 

/* global api */

Использование ESLint Config

Как объяснено здесь - добавьте это в ваш .eslintrc файл: 

{
  "globals": {
    "api": "writable"
  }
}

Примечание

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

1 голос
/ 16 июня 2019

Физический файл JavaScript с оператором импорта / экспорта по стандарту представляет собой модуль . Единственный файл .js без импорта / экспорта - это стандарт script . То, что вы пытаетесь сделать, не соответствует этому, в ECMAScript нет спецификации, которая позволяла бы разбивать один скрипт или модуль на несколько файлов. Я понимаю, откуда вы, например: C # имеет частичные классы, которые позволяют разделить класс на несколько файлов. Но пытаться воспроизвести это без стандартного синтаксиса нецелесообразно. Особенно, когда импорт / экспорт может и сделает всю работу за вас

Например, при следующих допущениях ваш main.js может быть изменен на 

constants.js // <--- constants
ui.js  // <--- logic to build UI
api.js  // <--- exposing public api
init.js  // <--- setup code before use

// main.js 
// If you name this index.js you can import it as 'src/main' instead of 'src/main/main.js'
import { A,B } from './constants'
import { api } from './api'
import { displayUi } from './ui'
import { init } from './init'

init(A);
displayUi(B);

export { api } // <-- re-expose public api
...