GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — require is not defined · Issue #7 · ModuleLoader/node-es-module-loader

This repository was archived by the owner on Jul 13, 2020. It is now read-only.
This repository was archived by the owner on Jul 13, 2020. It is now read-only.

require is not defined #7

Copy link
Copy link
Open
Open
require is not defined#7
Copy link

Description

@shellscape
shellscape
opened on Mar 16, 2017
Issue body actions

Given this snippet:

import bodyParser from 'koa-bodyparser';
import Koa from 'koa';

const chalk = require('chalk');

the result when trying to load this module is:

const chalk = require('chalk');
              ^
require is not defined

I understand from this issue ModuleLoader/es-module-loader#427 that the loader has made the assumption that the user only wants ES6 module support and not interoperability with require for CommonJS modules.

While that is a perfectly good and reasonable argument for the es-module-loader module, the node-esml binary would imply by README description and name that there is a measure of interoperability with Node's current and default loader mechanisms. This would follow use of babel in node server-side code in which we're able to use require within ES6 modules.

The 'sync' nature of require can be duplicated using async/await patterns on the dynamic import, however that can only be used on node > 7 with harmony flags, or node 7.6 - both of which are not yet options for a large chunk of developers due to restrictions in the workplace.

I'd like to at the least point out this limitation and the perception that it may be interpreted as a bug by folks not intimately familiar with loaders and/or es-module-loader. And I'd like to propose the interoperability with default node require support as a new feature.

Or at the least, an updated README with a solution to provide support for require. If I'm missing something where require-like capabilities exist, such as the ability to load JSON files as objects, then please do consider adding those to the README, as I haven't found a suitable workaround as simplistic as requiring the file.

Activity

  1. guybedford commented on Mar 16, 2017

    @guybedford
    guybedford
    on Mar 16, 2017
    Member
    More actions

    Mixing require and ES module syntax is not something that Node itself will be doing, so the goal of this project is to align with how things will work in future. Yes this workflow isn't quite ready for prime time yet, but it gets us close to it. Encouraging the right patterns and correctness is the goal here over trying to provide the very best workflow for the existing state of things today.

  2. shellscape commented on Mar 16, 2017

    @shellscape
    shellscape
    on Mar 16, 2017
    Author
    More actions

    Interesting, and thanks for addressing so quickly. I've been trying to stay ahead on the developments around that, but I clearly missed some discussion - any chance you have references you could share about that no-intermixing-module-types?

  3. chyzwar commented on May 19, 2017

    @chyzwar
    chyzwar
    on May 19, 2017
    More actions

    I wanted to use require to get synchronous code splitting. import() would make my constructor async.

    Would be possible to add something like System.delete from systemjs ?
    Do you know if spec for ES modules provide a way to unload module from registry?

  4. guybedford commented on May 20, 2017

    @guybedford
    guybedford
    on May 20, 2017
    Member
    More actions

    There is currently no spec for the registry API methods like System.delete. This project can't do anything until there is at least a candidate spec. This is the sort of thing that should be discussed at the spec-level first.

  5. chyzwar commented on May 20, 2017

    @chyzwar
    chyzwar
    on May 20, 2017
    More actions

    yeah, this is what I was guessing.

    Problem is that import() being asyc in browser make sense but not so much in node.

    I was thinking about hacking around with System.delete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.