fpipita / esm-middleware Goto Github PK

I have modules that I revolve dynamically, i.e. no file exists on disk for them to be loaded.

E.g.:

app.js:

import core from '/core'

While there's no file as "core" or "core.js", I resolve it dynamically:

server.js:

...
app.use(esm())
app.get('/core', (req, res) => {
   const core = getCore(...)
   res.send(core)
})

The problem is esm-middleware removes the entire line import core from '/core' from my app.js

I think it should give the user the choice not to remove any unresolved imports, like with an option: removeUnresolved: false

Getting error on Windows:

SyntaxError: Invalid regular expression: /\/: \ at end of pattern
    at new RegExp (<anonymous>)
    at Object.<anonymous> (C:\...\node_modules\esm-middleware\src\babel-plugin-esm-resolver.js:11:33)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at Object.<anonymous> (C:\...\node_modules\esm-middleware\src\esm-middleware.js:5:27)

Looking at the source I believe the fix could be:

-const PATH_SEPARATOR_REPLACER = new RegExp(path.sep, "g");
+const IS_WIN = process.platform === "win32"
+const PATH_SEPARATOR_REPLACER = new RegExp(IS_WIN ? "\\\\" : path.sep, "g");

Also, is this open source? Never mind, I thought the source code wasn't available on github for some reason (got linked to Readme from npm and thought the repo was empty).

Great lib BTW!

This would help consumers of this module to get started as typings would enable code completion and other nice development aids from their IDEs.

I want to serve up my "client" folder (from the example) as the root, instead of "/client" prefix.

-app.use("/client", express.static(path.resolve("client")));
+app.use(express.static(path.resolve("client")));

This is a pretty standard practice, it's also used by express-generator

This currently doesn't seem to be possible.

Repro: https://github.com/laggingreflex/esm-middleware-clientdir

I think it should take an input for what might be the root for resolving req.url paths... (just like it does nodeModulesRoot)

Some of the Node core globals/modules, e.g. Buffer, could be supported by injecting into the program scope the bindings from packages implementing the same functionality for the browser, e.g. https://github.com/feross/buffer.

At the moment, all the code processed by the middleware is transformed and the original formatting is lost.

Although the produced code is decently formatted and readable, it would be nice to have an opt-in behavior which allowed to map the served code 1:1 with the original source code.

One solution could be to produce and serve source maps along with the transformed source files.

At the moment, when package.json contains a browser field for a given module, it is only taken into account when the field contains a string.

We need to add support for the object type, which works as explained here.

Given the npm package "bar" whose main entry is the module:

my-app/node_modules/bar/index.js

module.exports.foo = 'foo';

accessing the foo named export from our source code is only possible through the default export:

/my-app/src/app.js

import bar from "bar";
console.log(bar.foo) // prints "foo"

because only the default export is made available to consumers by the middleware when requesting pure cjs modules.

It would be nice if it was possible to access bar via an esm named import indeed:

/my-app/src/app.js

import { foo } from "bar";
console.log(foo) // prints "foo"

Sorry if I misread something or am using it wrong, but in the examples it says that I could do

import _ from "lodash";

But this doesn't seem to work.

In the sourcecode I see why:

    const mimeType = mime.lookup(req.originalUrl);

For "lodash" mimeType is always false.