currently we have a few codemods which replace imports.
for example:
|
const didReplacement = replaceImport( |
|
j, |
|
root, |
|
{ moduleName: 'deep-equal', importName: 'default', cjsNamespace: true }, |
|
{ moduleName: 'dequal', importName: 'dequal', cjsNamespace: false }, |
|
); |
if something (such as the es-t cli) consumes these codemods, it doesn't currently have a way to know what you replaced the import with. we don't expose the fact that we replaced deep-equal with dequal.
in our case, it means the CLI doesn't know which new package to add to package.json.
i think we have two options here:
- the codemod owns the job of modifying
package.json (by checking the filename or something), and the CLI just calls the codemod on package.json contents
- all codemods that affect packages (imports) expose some kind of "result" which defines these (e.g.
[{type: 'remove', name: 'deep-equal'}, {type: 'add', name: 'dequal'}])
currently we have a few codemods which replace imports.
for example:
module-replacements-codemods/codemods/deep-equal/index.js
Lines 19 to 24 in c6fe8d7
if something (such as the es-t cli) consumes these codemods, it doesn't currently have a way to know what you replaced the import with. we don't expose the fact that we replaced
deep-equalwithdequal.in our case, it means the CLI doesn't know which new package to add to
package.json.i think we have two options here:
package.json(by checking the filename or something), and the CLI just calls the codemod onpackage.jsoncontents[{type: 'remove', name: 'deep-equal'}, {type: 'add', name: 'dequal'}])