jed/esbuild-plugin-http-fetch

An esbuild plugin that resolves http(s) modules

esbuild-plugin-http-fetch

An esbuild plugin that resolves http(s) modules, for use with browsers and Deno.

Example

// test/index.js
import {build, stop} from 'https://deno.land/x/[email protected]/mod.js'
import httpFetch from 'https://deno.land/x/[email protected]/index.js'

let {outputFiles} = await build({
  bundle: true,
  entryPoints: ['test/hello.jsx'],
  jsxFactory: 'h',
  plugins: [httpFetch],
  write: false
})

eval(outputFiles[0].text)
// expected: <h1>Hello, world!</h1>
// actual: <h1>Hello, world!</h1>

stop()

// test/hello.jsx
import {h} from 'https://unpkg.com/[email protected]/dist/preact.module.js'
import render from 'https://unpkg.com/[email protected]/dist/index.module.js?module'

let app = <h1>Hello, world!</h1>
let html = render(app)

console.log('expected: %s', '<h1>Hello, world!</h1>')
console.log('actual: %s', html)

esbuild-plugin-http-fetch's Issues

Make use of DENO_AUTH_TOKENS

Loader cannot be determined if url doesn't contain filename or filename isn't a loader

The current implementation determines the loader by the file extensions. This works well when importing from urls that contain a file extension like deno.land:

import { parse } from "https://deno.land/x/xml/mod.ts";

But it causes problems when the url doesn't contain a filename like esm.sh:
import {mainSymbols} from 'https://esm.sh/[email protected]';

Or when the file has an extension but the loaders name isn't exactly the same as the file extension, e.g. the 'js' loader can load files ending in .js, .cjs or .mjs, which happens with the deno node compatibility layer:
https://deno.land/[email protected]/node/internal/buffer.mjs

How could we fix this problem? I thought about checking the determined loader against a list of officially supported esbuild loaders and if it's not any of them just default to 'ts' because that would work for js and ts files. It still won't work if I one wants to import a json file that way, but that doesn't work now anyway so it won't make things worse.

I could also think of something like an import map option for the plugin that lets you override a loader for a url, that would be suitable for cases where it's absolute not possible to determine the correct loader from the url, but I think defaulting to the ts loader would be enough.

This is the workaround I'm currently using, If you think this is a suitable solution I'd be happy to submit a PR

 const allowedLoaders = ['js','ts','tsx','jsx','json','css','text','binary','base64','dataurl','file','copy']
    let {pathname} = new URL(source.url)
    let loader = pathname.match(/[^.]+$/)[0]
    if(!allowedLoaders.includes(loader)){
        loader = 'ts'
    }

Error on usage

Hi! I don't know if this is still maintained, but I have an issue when I try to use it:

const esbuild = await import("https://raw.githubusercontent.com/esbuild/deno-esbuild/main/mod.js")
const httpFetch = await import("https://deno.land/x/[email protected]/index.js") as any

try {
    await esbuild.build({
        plugins: [ httpFetch ],
        write: true,
        bundle: true,
        minify: false,
        entryPoints: [ entryFile ],
        outfile,
    })
    
    ...

When I run the above, I get:

 > error: Plugin at index 0 is missing a name

Error: Build failed with 1 error:
error: Plugin at index 0 is missing a name
    at failureErrorWithLog (https://raw.githubusercontent.com/esbuild/deno-esbuild/main/mod.js:1439:15)
    at https://raw.githubusercontent.com/esbuild/deno-esbuild/main/mod.js:982:18
    at https://raw.githubusercontent.com/esbuild/deno-esbuild/main/mod.js:977:9
    at https://raw.githubusercontent.com/esbuild/deno-esbuild/main/mod.js:573:9
    at handleIncomingPacket (https://raw.githubusercontent.com/esbuild/deno-esbuild/main/mod.js:670:9)
    at readFromStdout (https://raw.githubusercontent.com/esbuild/deno-esbuild/main/mod.js:540:7)
    at https://raw.githubusercontent.com/esbuild/deno-esbuild/main/mod.js:1709:11

Any help would be appreciated

Add caching