You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I help convert a lot of CJS project to ESM
And two rules that help make this migration way easier is if they have a single groped export at the bottom of the file:
// A single exports assignment -> okmodule.exports={
first,
second,}
// Multiple exports assignments -> not ok!module.exports.first=truemodule.exports.second=true
...then it's just a matter of changing one line:
- module.exports = {+ export = {
first,
second,
}
this makes it way easier to refactor into a ESM and it's more likely that others accepts one such PR, cuz they are also way easier to review and accept.
i think it's also easier to see / control what is being exported when everything is scattered around in the hole file from top to bottom.
Another reason for having exports at the bottom is b/c of this anti- pattern that makes it hard to refactor old prototype based classes to es classes
cuz those functions / variables are hosted to the top.
then when you go ahead and convert this to es classes then you can no longer do: module.exports = Circle at the top of the file
i see this pattern quite a bit from time to time. some think it's easer to declare what is being exported at the top of the file. but it's problematic. change Circle to a class or const/let and the Circle becomes undeclared.
this is why it would also help if exports where at the bottom instead.
I help convert a lot of CJS project to ESM
And two rules that help make this migration way easier is if they have a single groped export at the bottom of the file:
...then it's just a matter of changing one line:
this makes it way easier to refactor into a ESM and it's more likely that others accepts one such PR, cuz they are also way easier to review and accept.
i think it's also easier to see / control what is being exported when everything is scattered around in the hole file from top to bottom.
Another reason for having exports at the bottom is b/c of this anti- pattern that makes it hard to refactor old prototype based classes to es classes
cuz those functions / variables are hosted to the top.
then when you go ahead and convert this to es classes then you can no longer do:
module.exports = Circle
at the top of the filei see this pattern quite a bit from time to time. some think it's easer to declare what is being exported at the top of the file. but it's problematic. change Circle to a class or const/let and the
Circle
becomes undeclared.this is why it would also help if exports where at the bottom instead.
There are two rules that helps with this:
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/group-exports.md
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/exports-last.md
which i think should be added.
The text was updated successfully, but these errors were encountered: