René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Pluggable Loaders to support multiple use cases","articleBody":"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 https://github.com/nodejs/node/pull/18392\r\n\r\nTLDR; (bluesky)\r\n\r\n* Loader Plugins can be specified via an out of band mechanism (a.k.a. package.json or command line argument). \r\n* Loader Plugins can included within a project as an es module or installed via a package manager\r\n* Loader Plugins can specify the behavior of the loader including\r\n  - behavior for specific extensions or mimetypes\r\n  - behavior for lack of extensions (e.g. path searching)\r\n* Loader Plugins can cascade\r\n  - plugins can override default behavior\r\n\r\nExample loaders include\r\n  - std/esm\r\n  - TypeScript\r\n  - wasm\r\n  - Babel\r\n\r\nQuestions to be answered\r\n\r\n* Is this approach of interest?\r\n* Should plugins be specified per application or per package\r\n* What should node ship as default loaders?\r\n  - Proposal\r\n    - Package name map as default loader\r\n    - \"Legacy\" loader shipped in core as well\r\n\r\nThoughts?","author":{"url":"https://github.com/MylesBorins","@type":"Person","name":"MylesBorins"},"datePublished":"2018-05-14T21:28:16.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":88},"url":"https://github.com/82/modules/issues/82"}