issue 429 javascript module imports

[hutchgrant]

Related Issue

#429

Summary

This is a test PR demonstrating the issue related to javascript module imports of unsupported libraries

Problems

• problems related to javascript library imports for unsupported libraries e.g. redux, lodash, (for this example)

lodash

Uncaught (in promise) SyntaxError: The requested module 'blob:http://localhost:1984/ec43201d-db76-4dd3-943a-02002e7c8fb9' does not provide an export named 'default'
async function (async)
topLevelLoad @ es-module-shims.js:252
processScripts @ es-module-shims.js:453
(anonymous) @ es-module-shims.js:440
(anonymous) @ es-module-shims.js:472

redux - related to a transform path?

es-module-shims.js:409 Uncaught (in promise) Error: Unknown Content-Type ""
    at es-module-shims.js:409

[thescientist13]

Rebased and recommitted changes on top of new Resource based plugins API, and have been able to get redux and pwa-helpers working so far.

It looks like for lit-redux-router, I "might" have to make the importMap generation recursive to handle deps of deps, but so far making OK progress in this minefield that is multiple module formats on NodeJS. 😳

[thescientist13]

Latest status (will be continuously updating this comment) but it's pretty much almost there!

Summary

1. Adding support for more types of npm packages like redux, pwa-helpers, and lit-redux-router
2. Handle .mjs entry points by extending pluginNodeModules with additional Resource lifecycles
3. Refactored importMap to build up from transitive dependencies of the project
4. Created a standalone plugins-import-commonjs plugin that is now integrated and encapsulating all CommonJS related logic. Using a bit of hack in regards to CJS detection though, but. it is working and not interferring adversely with ESM / MJS (yet) so 🤞
5. Refactored all ResourceInterface methods to be async
6. Refactored shouldOptimize / optimize to follow pattern of using url and body, but expects a body in return
7. Added new test cases

TODO

1. Continue testing with packages like lodash and apollo
2. Tests
3. Documentation
4. Resolve "empty" importMap entry (nice to have)

   "": "/node_modules/",

5. clean up console logs / test.js code
6. Open an issue with cjs-module-lexer to see if a test / validate method could be supported, so we can undo our try / catch hack

Thoughts

• cache importMap so it is only built one time when the server starts, not on every request?
• this is a good exercise / opportunity in measuring our prior dependencies, to see if "lighter" alternatives exist
• explore support for more module formats / entry detection, e.g. jsnext:main?

[thescientist13]

Got a bunch of tests in place now, and synced the docs. Things are feeling pretty solid now.

As a side note, I did play around with apollo for a bit, and it definitely seems pretty coupled to React. I think for our data / GraphQL support plugin, we should consider going with an alternative that is more lighter weight and has less tight coupling to anyone particular frontend framework. Thinking we could give urql a try?

[thescientist13]

This is good to go! 🎉