Не работает import node js

Импорт не работает на Node.js версии 11.8.0

Я пишу простую программу, которая использует объект, полный словарных слов. Я хочу импортировать этот объект из другого файла, так как он очень большой. При попытке импортировать его я получаю сообщение об ошибке, которое выглядит так, будто Node.js не знает, что это такое.

Я уже пытался переустановить последнюю версию Node.js.

Вот суть словарного кода:

Я ожидал, правда, но я получил эту ошибку:

ECMAScript 6 сейчас работает, но я получаю ошибку, что dict не определен. Может ли это быть как-то связано с размером файла, потому что я несколько раз проверил орфографические ошибки?

3 ответа

Вы могли использовать клавиатуру import где-то еще в вашем коде? Проблема может заключаться в том, что вы не переносите свой код в ECMAScript 5. Поскольку import является функцией ECMAScript 6, она еще не полностью поддерживается Node.js. Если вы используете такой инструмент, как Babel, для переноса своего кода, вы можете решить эту проблему. Если вы не хотите этого делать, попробуйте вместо этого использовать require .

Как уже отмечалось, в Node.js 9+ вы также можете использовать его в файлах .mjs с включенным флагом —experimental-modules .

Поддерживается только с экспериментальным флагом. Вы должны использовать флаг —experimental-modules .

Или просто используйте require, как это, или, если вы действительно хотите, вы можете передать свой код с помощью browserify, babel или parcel или чего-либо еще.

Я думаю, что это должно работать, если вы запускаете такой код:

Обратите внимание, что он использует расширение mjs (модульный JavaScript, я думаю).

Источник

Исправить Невозможно использовать оператор импорта за пределами модуля. Проблема

Я пытался загрузить некоторые JS-файлы и столкнулся с этой странной ошибкой «Невозможно использовать оператор импорта вне модуля» и не смог продолжить кодирование. Проведя небольшое исследование, я нашел несколько решений для устранения проблемы. Я надеюсь, что это поможет вам исправить ошибку Cannot use import за пределами узла модуля.

Самое простое решение для проблемы

Статический import Оператор используется для импорта привязок, которые экспортируются другим модулем.

Импортированные модули находятся в strict mode объявляете ли вы их таковыми или нет.

Освободи Себя import оператор не может быть использован во встроенных сценариях, если сценарий не имеет type=»module» , Вот пример для оператора import с типом module.

Другие решения

Существует много причин, по которым вышеупомянутая проблема может возникнуть. Например, вы можете найти файл в src каталог вместо встроенного файла в dist каталог.

Это означает, что вы используете собственный исходный код в неизмененном / несвязанном состоянии, что приводит к следующей ошибке: Uncaught SyntaxError: Cannot use import statement outside a module , Вы можете решить эту проблему, создав файл сценария и импортировав его.

Другая проблема может быть в том, что вы загружаете файл, который использует es6 с нормальным js файлы, вы должны сначала скомпилировать es6 а затем загрузите файлы, чтобы исправить проблему

Я получил эту ошибку, потому что я забыл type = ”module” внутри тега скрипта, поэтому вот как я исправил проблему:

Я просто добавил type = ”module” с тегом script, и проблема была решена.

Еще одно решение

Ошибка может возникнуть, если файл, на который вы ссылаетесь в своем HTML-файле, является несвязанной версией файла. Чтобы получить полную версию в комплекте, вам необходимо установить ее с помощью npm :

Когда вы запустите указанную выше команду, она сохранит пакет в каталоге node_modules, а затем вы можете связать файл по адресу node_modules/package_to_save/dist/file.js

Окончательное решение 2020 Обновление

Убедитесь, что у вас установлена ​​последняя версия Node.

Если у вас последняя версия узла, то —experimental-modules флаг больше не нужен.

Просто воспользуйтесь любой из следующих опций, чтобы решить проблему:

• Добавить «type»: «module» ближайшему родителю package.json , С этим все .js и .mjs файлы интерпретируются как модули ES. Вы можете интерпретировать отдельные файлы как CommonJS, используя .cjs расширение.

OR

• Явно назовите файлы с .mjs расширение. Все остальные файлы, такие как .js будет интерпретироваться как CommonJS, который используется по умолчанию, если type не определен в package.json .

Узнайте об импорте в Javascript здесь для лучшего понимания импорта файлов. Понимание импорта и экспорта файлов поможет вам оптимизировать оператор Cannot use import вне модуля в nodejs.

Источник

why export and import error in node.js 9?

I am learning the javascript not long. I make two files like bellow. app.js:

And i just run the command in console:

It was err. The err msg:

Can anyone tell me why? And what is about the javascript and babel and so on. I am not so familiar about the concepts. Thanks.

4 Answers 4

There is a comity that each year promote a new javascript norm that are called ECMA 2015 (ES6), ECMA 2016 (ES7), ECMA 2017 (ES8) .

Each norm describe the functionality javascript must have.

It exists multiple javascript engines in the market:

• V8 from google (and node)
• Chakra from microsoft
• Rhino from mozilla

Theses engines try to keep up to the norm, but are not 100% compliant.

here you can see a compatibility table about the engines and ES6.

The problem you can imagine now, is «Why if I want to use the brand new ES8 right away?». There is two answer: Either you wait for node.js to implement it, either you use a transpiler like Babel.

Babel takes the code you do and transpile it into an older norm (ES5) which is fully compatible with node.js.

For example, you want to use import which is an ES6 feature. Babel gonna transform your import into require so node.js can execute it.

It’s very usefull and powerfull to use a transpiler so you an use right away the last feature that are improving the productivity of your developper team.

Источник

Экспорт и импорт

Директивы экспорт и импорт имеют несколько вариантов вызова.

В предыдущей главе мы видели простое использование, давайте теперь посмотрим больше примеров.

Экспорт до объявления

Мы можем пометить любое объявление как экспортируемое, разместив export перед ним, будь то переменная, функция или класс.

Например, все следующие экспорты допустимы:

Обратите внимание, что export перед классом или функцией не делает их функциональным выражением. Это всё также объявление функции, хотя и экспортируемое.

Большинство руководств по стилю кода в JavaScript не рекомендуют ставить точку с запятой после объявлений функций или классов.

Поэтому в конце export class и export function не нужна точка с запятой:

Экспорт отдельно от объявления

Также можно написать export отдельно.

Здесь мы сначала объявляем, а затем экспортируем:

…Или, технически, мы также можем расположить export выше функций.

Импорт *

Обычно мы располагаем список того, что хотим импортировать, в фигурных скобках import <. >, например вот так:

Но если импортировать нужно много чего, мы можем импортировать всё сразу в виде объекта, используя import * as . Например:

На первый взгляд «импортировать всё» выглядит очень удобно, не надо писать лишнего, зачем нам вообще может понадобиться явно перечислять список того, что нужно импортировать?

Для этого есть несколько причин.

Современные инструменты сборки (webpack и другие) собирают модули вместе и оптимизируют их, ускоряя загрузку и удаляя неиспользуемый код.

Предположим, мы добавили в наш проект стороннюю библиотеку say.js с множеством функций:

Теперь, если из этой библиотеки в проекте мы используем только одну функцию:

…Тогда оптимизатор увидит, что другие функции не используются, и удалит остальные из собранного кода, тем самым делая код меньше. Это называется «tree-shaking».

Явно перечисляя то, что хотим импортировать, мы получаем более короткие имена функций: sayHi() вместо say.sayHi() .

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

Импорт «как»

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

Например, для краткости импортируем sayHi в локальную переменную hi , а sayBye импортируем как bye :

Экспортировать «как»

Аналогичный синтаксис существует и для export .

Давайте экспортируем функции, как hi и bye :

Теперь hi и bye – официальные имена для внешнего кода, их нужно использовать при импорте:

Экспорт по умолчанию

На практике модули встречаются в основном одного из двух типов:

1. Модуль, содержащий библиотеку или набор функций, как say.js выше.
2. Модуль, который объявляет что-то одно, например модуль user.js экспортирует только class User .

По большей части, удобнее второй подход, когда каждая «вещь» находится в своём собственном модуле.

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

Модули предоставляют специальный синтаксис export default («экспорт по умолчанию») для второго подхода.

Ставим export default перед тем, что нужно экспортировать:

Заметим, в файле может быть не более одного export default .

…И потом импортируем без фигурных скобок:

Импорты без фигурных скобок выглядят красивее. Обычная ошибка начинающих: забывать про фигурные скобки. Запомним: фигурные скобки необходимы в случае именованных экспортов, для export default они не нужны.

Именованный экспорт	Экспорт по умолчанию
export class User	export default class User
import from .	import User from .

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

Так как в файле может быть максимум один export default , то экспортируемая сущность не обязана иметь имя.

Например, всё это – полностью корректные экспорты по умолчанию:

Это нормально, потому что может быть только один export default на файл, так что import без фигурных скобок всегда знает, что импортировать.

Без default такой экспорт выдал бы ошибку:

Имя «default»

В некоторых ситуациях для обозначения экспорта по умолчанию в качестве имени используется default .

Например, чтобы экспортировать функцию отдельно от её объявления:

Или, ещё ситуация, давайте представим следующее: модуль user.js экспортирует одну сущность «по умолчанию» и несколько именованных (редкий, но возможный случай):

Вот как импортировать экспорт по умолчанию вместе с именованным экспортом:

И, наконец, если мы импортируем всё как объект import * , тогда его свойство default – как раз и будет экспортом по умолчанию:

Довод против экспортов по умолчанию

Именованные экспорты «включают в себя» своё имя. Эта информация является частью модуля, говорит нам, что именно экспортируется.

Именованные экспорты вынуждают нас использовать правильное имя при импорте:

…В то время как для экспорта по умолчанию мы выбираем любое имя при импорте:

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

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

Тем не менее, в некоторых командах это считают серьёзным доводом против экспортов по умолчанию и предпочитают использовать именованные экспорты везде. Даже если экспортируется только одна вещь, она всё равно экспортируется с именем, без использования default .

Это также немного упрощает реэкспорт (смотрите ниже).

Реэкспорт

Синтаксис «реэкспорта» export . from . позволяет импортировать что-то и тут же экспортировать, возможно под другим именем, вот так:

Зачем это нужно? Рассмотрим практический пример использования.

Представим, что мы пишем «пакет»: папку со множеством модулей, из которой часть функциональности экспортируется наружу (инструменты вроде NPM позволяют нам публиковать и распространять такие пакеты), а многие модули – просто вспомогательные, для внутреннего использования в других модулях пакета.

Структура файлов может быть такой:

Мы бы хотели сделать функциональность нашего пакета доступной через единую точку входа: «главный файл» auth/index.js . Чтобы можно было использовать её следующим образом:

Идея в том, что внешние разработчики, которые будут использовать наш пакет, не должны разбираться с его внутренней структурой, рыться в файлах внутри нашего пакета. Всё, что нужно, мы экспортируем в auth/index.js , а остальное скрываем от любопытных взглядов.

Так как нужная функциональность может быть разбросана по модулям нашего пакета, мы можем импортировать их в auth/index.js и тут же экспортировать наружу.

Теперь пользователи нашего пакета могут писать import from «auth/index.js» .

Запись export . from . – это просто более короткий вариант такого импорта-экспорта:

Реэкспорт экспорта по умолчанию

При реэкспорте экспорт по умолчанию нужно обрабатывать особым образом.

Например, у нас есть user.js , из которого мы хотим реэкспортировать класс User :

export User from ‘./user.js’ не будет работать. Казалось бы, что такого? Но возникнет синтаксическая ошибка!

Чтобы реэкспортировать экспорт по умолчанию, мы должны написать export , как в примере выше. Такая вот особенность синтаксиса.

export * from ‘./user.js’ реэкспортирует только именованные экспорты, исключая экспорт по умолчанию.

Если мы хотим реэкспортировать и именованные экспорты и экспорт по умолчанию, то понадобятся две инструкции:

Такое особое поведение реэкспорта с экспортом по умолчанию – одна из причин того, почему некоторые разработчики их не любят.

Итого

Вот все варианты export , которые мы разобрали в этой и предыдущей главах.

Вы можете проверить себя, читая их и вспоминая, что они означают:

• Перед объявлением класса/функции/…:
  • export [default] class/function/variable .
• Отдельный экспорт:
  • export .
• Реэкспорт:
  • export from «module»
  • export * from «module» (не реэкспортирует export default ).
  • export from «module» (реэкспортирует только export default ).

• Именованные экспорты из модуля:
  • import from «module»
• Импорт по умолчанию:
  • import x from «module»
  • import from «module»
• Всё сразу:
  • import * as obj from «module»
• Только подключить модуль (его код запустится), но не присваивать его переменной:
  • import «module»

Мы можем поставить import/export в начало или в конец скрипта, это не имеет значения.

То есть, технически, такая запись вполне корректна:

На практике импорты, чаще всего, располагаются в начале файла. Но это только для большего удобства.

Обратите внимание, что инструкции import/export не работают внутри <. >.

Условный импорт, такой как ниже, работать не будет:

…Но что, если нам в самом деле нужно импортировать что-либо в зависимости от условий? Или в определённое время? Например, загрузить модуль, только когда он станет нужен?

Мы рассмотрим динамические импорты в следующей главе.

Источник