Error unexpected require global require

The ESLint website. Contribute to eslint/archive-website development by creating an account on GitHub.
title layout

Rule global-require

doc

Enforce require() on the top-level module scope. (global-require)

In Node.js, module dependencies are included using the require() function, such as:

While require() may be called anywhere in code, some style guides prescribe that it should be called only in the top level of a module to make it easier to identify dependencies. For instance, it’s arguably harder to identify dependencies when they are deeply nested inside of functions and other statements:

function foo() {

    if (condition) {
        var fs = require("fs");
    }
}

Since require() does a synchronous load, it can cause performance problems when used in other locations.

Further, ES6 modules mandate that import and export statements can only occur in the top level of the module’s body.

Rule Details

This rule requires all calls to require() to be at the top level of the module, similar to ES6 import and export statements, which also can occur only at the top level.

You can enable this rule with the following syntax:

The following patterns are considered problems:

/*eslint global-require: 2*/
/*eslint-env es6*/

// calling require() inside of a function is not allowed
function readFile(filename, callback) {
    var fs = require('fs');                                /*error Unexpected require().*/
    fs.readFile(filename, callback)
}

// conditional requires like this are also not allowed
if (DEBUG) { require('debug'); }                           /*error Unexpected require().*/

// a require() in a switch statement is also flagged
switch(x) { case '1': require('1'); break; }               /*error Unexpected require().*/

// you may not require() inside an arrow function body
var getModule = (name) => require(name);                   /*error Unexpected require().*/

// you may not require() inside of a function body as well
function getModule(name) { return require(name); }         /*error Unexpected require().*/

// you may not require() inside of a try/catch block
try {
    require(unsafeModule);                                 /*error Unexpected require().*/
} catch(e) {
    console.log(e);
}

The following patterns are not considered problems:

/*eslint global-require: 2*/

// all these variations of require() are ok
require('x');
var y = require('y');
var z;
z = require('z').initialize();

// requiring a module and using it in a function is ok
var fs = require('fs');
function readFile(filename, callback) {
    fs.readFile(filename, callback)
}

// you can use a ternary to determine which module to require
var logger = DEBUG ? require('dev-logger') : require('logger');

// if you want you can require() at the end of your module
function doSomethingA() {}
function doSomethingB() {}
var x = require("x"),
    z = require("z");

When Not To Use It

If you have a module that must be initialized with information that comes from the file-system or if a module is only used in very rare situations and will cause significant overhead to load it may make sense to disable the rule. If you need to require() an optional dependency inside of a try/catch, you can disable this rule for just that dependency using the // eslint disable-line global-require comment.

Version

This rule was introduced in ESLint 1.4.0.

Resources

  • Rule source
  • Documentation source
Источник

Немного непоследовательно то, что это правило разрешает троичный условный импорт, но не разрешает условный импорт логических выражений. Ты уверен, что здесь мы ничего не можем сделать, @mysticatea?

@mysticatea
Но … это неправильно. Правило не запрещает условный импорт. Использование тернарного выражения для определения требуемого модуля явно разрешено в соответствии с документацией .
Это означает, что если целью правила является имитация выражений import (что, кстати, вообще не видно из документации), тогда оно также терпит неудачу, поскольку эти afaik не могут использоваться в тернарных выражениях.

Так или иначе, здесь что-то не так.

Я согласен. Либо это правило не должно проверять логические выражения, либо оно также должно проверять троичные.

Ой, извини, что не заметил.
Хм, хотелось бы услышать мнение автора.

Итак … что-то еще происходит по этой проблеме?

имо ошибка в том, что он также не проверяет троичные файлы.

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

Я думаю, проблема здесь в том, что в документации к import ».

Любой из них будет относительно просто реализовать, но пока мы не решим, что правило пытается делать в первую очередь, я не могу решить, является ли какое-либо промежуточное поведение ошибкой. (В качестве отдельного примечания, учитывая, что использование троичных файлов явно разрешено в документации, я не уверен, что для нас было бы разумным начать запрещать их по умолчанию и называть это исправлением ошибки.)

Он имеет очень четко определенное значение — это означает, что в области верхнего уровня; что означает «не внутри фигурных скобок».

Вы имеете в виду, что в области верхнего уровня следует учитывать следующее? Ни один из них не находится в фигурных скобках.

const bar = x ? require('baz') : require('qux');
const foo = () => require('a');

Я не пытаюсь придираться — я просто хочу полностью понять поведение, которое вы описываете. Описание его в терминах лексических областей видимости имеет смысл и будет согласованным, но это приведет к разрешению тернарейов, против чего, как я думал, вы возражали с https://github.com/eslint/eslint/issues/8784#issuecomment -313285770 .

Лол, хорошо, фигурные скобки или неявные блоки, такие как if / else / do / while и стрелочные функции неявного возврата.

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

Чтобы уточнить, я думаю, что это правило касается обеспечения соблюдения, которое требует, как операторы импорта, а не то, что они «верхнего уровня».

Следует ли это допустить?

const foo = require('bar').baz();

global-require настоящее время позволяет это, но было бы невозможно преобразовать его в оператор импорта, потому что для этого потребовалось бы два оператора, если бы использовался import (один для импорта и один для метода вызов).

Да, это должно быть разрешено — я не думаю, что правило должно предотвращать «требует, чтобы нельзя было импортировать в одном операторе» — требуется только то, что не может стать импортом.

Понятно, спасибо за объяснение. Что вы описываете , кажется , это было бы полезно для обеспечения, но я обеспокоен тем , что это было бы существенным изменение текущего поведения global-require правила (текущее правило не заботится ли в require является динамическим и явно разрешает условные требования).

В этом случае исходный пример должен пройти.

Итак, если мы разрешаем условные требования и динамические требования (поскольку предыдущая версия правила разрешала их), будет ли правило просто запрещать требования за пределами лексической области верхнего уровня?

Мне кажется, что это правило может брать на себя слишком большую ответственность. Я думаю, нам следует подумать о разделении этого на два правила с ESLint 5.x:

  • global-require гарантирует, что любой вызов (без тени) require() должен находиться в глобальной области или области модуля, то есть не в области блока или функции. Его не волнует, как вызывается require() .
  • Новое правило no-conditional-require гарантирует, что вызовы require() не могут быть в ConditionalExpression или LogicalExpression.

Это имело бы смысл?

Все это поведение может быть реализовано с помощью no-restricted-syntax любом случае, поэтому я немного против добавления новых правил для него.

Объединение всего в no-restricted-syntax очень затрудняет настройку в общей конфигурации, потому что нет способа указать в JSON / YML, который я хочу добавить к существующему массиву ограниченных синтаксисов — что означает, что мне нужно собрать и скопируйте / вставьте весь список из любого места, где он определен.

Кроме того, require не является синтаксисом.

Объединение всего в no-restricted-syntax очень затрудняет настройку в общей конфигурации, потому что нет способа указать в JSON / YML, который я хочу добавить к существующему массиву ограниченных синтаксисов — что означает, что мне нужно собрать и скопируйте / вставьте весь список из любого места, где он определен.

Я согласен. Я хотел сделать предложение, чтобы упростить задачу.

Кроме того, require не является синтаксисом.

Вы можете выбрать его с помощью CallExpression[callee.name="require"] .

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

Я бы сказал, что, возможно, одно правило, которое регулирует все аспекты node require , с опциями для управления различными вещами, и которое срабатывает, когда env не node , было бы полезно.

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

Была ли эта страница полезной?

0 / 5 — 0 рейтинги

Источник

Теги:  Unexpected require() (global-r  Решите проект Vue с помощью require () для компиляции ошибки  require()

Я цитирую такие картинки

Но при компиляции сообщалось об ошибке, как показано ниже

Решение:

В файле .eslintrc.js в проекте vue добавьте следующий код PS: Если нет, создайте его в корневом каталоге

module.exports = {
  rules: {
    
    "global-require": 0  
  },
  
};

Затем перезапустите проект.

Интеллектуальная рекомендация

указатель-события: нет; решить проблему сбоя клика

На работе сделал выпадающий список. Фон стрелки вниз добавляется к form-select :: after, но при нажатии стрелки событие раскрывающегося списка не может быть запущено. Так что добавьтеpointer-events: n…

Как идея соединяет MySQL?

1. Открытая идея 2. Справа есть база данных, щелкните 3. Нажмите » +» 4. Продолжайте нажимать 5. Выберите MySQL 6. Введите, где находится база данных, имя пользователя, пароль, тестовое соед…

CSRF и SSRF

Введение в уязвимости CSRF CSRF (подделка межсайтовых запросов, подделка межсайтовых запросов) относится к использованию недействительной идентификационной информации жертвы (файлы cookie, сеансы и т….

Разработка управления приложениями

Получить всю информацию о приложении PackageManager Android управляет пакетами приложений через PackageManager, и мы можем использовать его для получения информации о приложениях на текущем устройстве…

Вам также может понравиться

Анализ исходного кода пула потоков -jdk1.8

openjdk адрес загрузки http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/tags Логические шаги пула потоков, с которыми поставляется Java, — это, в основном, следующие шаги: Реализация псевдокода Отправить ис…

Используйте инструменты в макете XML:

В макете, если некоторые фиксированные значения атрибута не установлены, некоторое представление не будет видно, когда будет видна макет. Все, что мы можем увидеть эффект предварительного просмотра, к…

Войдите в JVM

1. Введение в JVM 1.1 Концепция JVM Введение в виртуальную машину: JVM (аббревиатура от Java Virtual Machine. Java Virtual Machine.), JVM — это настраиваемый компьютер, которого на самом деле не сущес…

пользователи Linux и группы пользователей

Пользователь категория Профиль пользователь Root (Root пользователя) Команда Советы Упорядочить #, имеет самую высокую задачу разрешения любого разрешения файла недействительно для корневого пользоват…

Котлин Базовый — класс и атрибуты

Давайте напишем простой JavaBean класса Student в Java, только с одним свойством, имя. Тот же класс в Котлин это: PUBLIC в Котлин является видимость по умолчанию, поэтому его можно опустить. Этот вид …

Источник

Понравилась статья? Поделить с друзьями:
  • Error unexpected rcode refused
  • Error unexpected matlab operator
  • Error unexpected matlab expression
  • Error unexpected local declaration in procedure body
  • Error unexpected junk after else statement at 1