Skip to content
This repository was archived by the owner on Sep 2, 2023. It is now read-only.
This repository was archived by the owner on Sep 2, 2023. It is now read-only.

Pluggable Loaders to support multiple use cases #82

Closed
@MylesBorins

Description

@MylesBorins

As #81 is getting into implementation details of the loader I thought it might be a good idea to start discussing an idea I have been kicking around for a robust solution. "Pluggable Loaders". This is heavily inspired by nodejs/node#18392

TLDR; (bluesky)

  • Loader Plugins can be specified via an out of band mechanism (a.k.a. package.json or command line argument).
  • Loader Plugins can included within a project as an es module or installed via a package manager
  • Loader Plugins can specify the behavior of the loader including
    • behavior for specific extensions or mimetypes
    • behavior for lack of extensions (e.g. path searching)
  • Loader Plugins can cascade
    • plugins can override default behavior

Example loaders include

  • std/esm
  • TypeScript
  • wasm
  • Babel

Questions to be answered

  • Is this approach of interest?
  • Should plugins be specified per application or per package
  • What should node ship as default loaders?
    • Proposal
      • Package name map as default loader
      • "Legacy" loader shipped in core as well

Thoughts?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions