-
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert to ESM #222
Convert to ESM #222
Conversation
Converted the entire app, and fixed all the tests - however, the |
I've managed to cover the async dependency problem with a sort-of kludgey Now it seems that the build behaviour is different for different versions of Node. Node 14 is the most angery, with not even the |
Codecov Report
@@ Coverage Diff @@
## master #222 +/- ##
==========================================
+ Coverage 94.54% 96.67% +2.12%
==========================================
Files 35 35
Lines 1247 4449 +3202
==========================================
+ Hits 1179 4301 +3122
- Misses 68 148 +80
Continue to review full report at Codecov.
|
ESM conversion seems to now be complete, with all tests and linter finally happy. Also tested the app manually, and all major features seem to work fine (and some runtime errors are not caught by current tests, I noticed). There's still some doubt in my mind if this is actually even beneficial. Pros
Cons
As a side effect of working on this PR, two clear benefits included here are;
However, these benefits aren't dependent on ESM in any way. |
On balance, I think while the conversion to ESM has required some inelegant solutions and upheavals, and carries some (possibly unknown) risk, the requirement for ESM to merge new versions of dependencies will only become more common. And I'd rather import this risk now than under the gun. Hopefully the inelegance can be smoothed over over time. |
To keep up with The Way Forward, and in order to merge #221, the entire codebase should be converted to ESM.
This still doesn't work properly yet. Importing the render and DB drivers dynamically is broken, as importing is async, but constructors cannot be. It also doesn't seem to be catching exceptions properly for some reason.
It's hard to say yet why, but it seems like some functioning(?) tests are also now returning different values than expected, though nothing else has changed.
I'm also still skeptical if there's actually any benefit to doing this. The app isn't any faster or otherwise better, and ESM doesn't make the code easier to understand or write. In fact, I'd argue that some of the funky patterns make the code actively worse (i.e.
(await import('../_utils/app.js')).default();
vs justrequire('../_utils/app.js')()
).Closes #210