Allow users to use ESM generated code#39
Conversation
andresgutgon
force-pushed
the
feature/add-esm-module-option
branch
from
57d5225 to
88b0681
Compare
|
Hi @derrickreimer. Sorry for the delay but I pick this project only during weekends :). I did the change you suggested about making cache busting optional. |
andresgutgon
force-pushed
the
feature/add-esm-module-option
branch
4 times, most recently
from
07736fb to
d7bc9cc
Compare
Support for ESM module execution was added in [elxir-nodejs 3.0](revelrylabs/elixir-nodejs#83) so I think we can use it in inertia.
andresgutgon
force-pushed
the
feature/add-esm-module-option
branch
from
d7bc9cc to
6b3e488
Compare
| ``` | ||
| `:esm_cache_busting` Useful for forcing reloads of your ssr.js file in environments that use dynamic imports. Defaults to false. In most cases, you’ll want to keep this set to false in production, since the generated JS file doesn't change frequently | ||
|
|
||
| `:esm_module_extension` Sets the file extension for the generated ESM module. Defaults to "mjs". You’ll need to configure your JS bundler to output the ssr.js file with the .mjs extension so that Node.js recognizes it as an ESM module. |
There was a problem hiding this comment.
I added this option for allowing to pass ssr file extension is helpful because elixir-nodejs under the hood use CommonJS and if you're using esm by setting esm: true the file with .js will be interpreted as commonjs instead of esm. But if you're file has the .mjs extension you don't need to do anything
ESM and the running working on commonjs can coexist.
I really think NodeJS module system is super confusing 😂 but it's what it is and we should push for using ESM whenever we can. CommonJS has to die bit by bit.
|
I decided to try another approach. I will close this one |
2 participants
What?
Support for ESM module execution was added in elxir-nodejs 3.0 so I think we can use it in inertia.
Issue
This PR address this issue
#38