docs: modernize 'Writing a Loader' guide to ESM syntax#7979
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| import { Volume, createFsFromVolume } from "memfs"; | ||
| import webpack from "webpack"; | ||
|
|
||
| const __filename = fileURLToPath(import.meta.url); |
There was a problem hiding this comment.
This is an obsolete way to get the filename and dirname nowadays in Node.js -- you can check the new way on Node.js docs or even ask AI for it.
There was a problem hiding this comment.
But the TL;DR is import.meta.dirname and import.meta.filename
There was a problem hiding this comment.
Thank you for the review! I've updated both examples to use
'import.meta.dirnameinstead of thefileURLToPath` approach.
| ### Common Code | ||
|
|
||
| Avoid generating common code in every module the loader processes. Instead, create a runtime file in the loader and generate a `require` to that shared module: | ||
| Avoid generating common code in every module the loader processes. Instead, create a runtime file in the loader and `import` it as a shared module: |
There was a problem hiding this comment.
We should write here that commonjs syntax supported too, but we recommended to use ECMA modules
There was a problem hiding this comment.
Thanks for the review @alexander-akait! I have updated the prose to explicitly mention that require is still supported while recommending import.
There was a problem hiding this comment.
Also restored the missing
memfs import that was accidentally removed.
3 participants
Summary
The "Writing a Loader" guide was mixing CommonJS (
require/module.exports)and ESM (
import/export) syntax across different code examples, which isconfusing for readers. This PR makes all examples consistent by using ESM
throughout. It also fixes a missing
__dirnamedefinition in thetest/compiler.jsexample that would cause a runtime error in an ESM context.part of #7772
What kind of change does this PR introduce?
docs
Did you add tests for your changes?
No — this is a documentation-only change. No functional code was modified.
Does this PR introduce a breaking change?
No.
If relevant, what needs to be documented once your changes are merged or what have you already documented?
No additional documentation needed. This PR is itself a documentation fix.
Use of AI
I used an AI assistant to help identify inconsistencies
in the file and understand the difference between CommonJS and ESM module
syntax. All code changes were applied manually by me. I reviewed
the webpack AI policy before submitting.