Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Opening this for discussion. Context:
By default, jscodeshift use babel to transform the transform files (i.e. the "plugins") themselves before running them in Node. The motivation of this seems to be to allow using more modern features in the transform plugins.
In the "old days" this may be necessary/desirable, but with modern Node versions having pretty good support for modern features/syntaxes, this benefit seems margin/dubious, and it can sometimes cause problem.
One example is that we tried to use
@embroider/core
in our transform, which depends on a fairly old package calledsourcemap-validator
. The source code of the package is NOT written with strict mode in mind, but the default settings for jscodeshift's babel transform blindly adds the"use strict";
declaration on top of each file, including dependencies in node_modules.This ultimately causes a hard error when running the codemod, in this case a
ReferenceError: createBuffer is not defined
when loading the file. Coincidentally thejscodeshift
set up of running things in workers and babel overridingrequire()
in Node also makes it harder to discover the root cause of the problem.It's unclear what can be done about this – I tried adding an empty
.babelrc
on the transform plugin side but that doesn't seem to be picked up. I am not sure how we are supposed to customize the babel options used for this purpose (which also further diminishes its utility).Ultimately, given the utility of this seems dubious on modern node, most transforms probably do not take advantage of this and most authors and consumers probably aren't aware of this little-known feature on
jscodeshift
, it's easier to just disable that which would probably make things run a little faster.It's also unclear if this ever worked "correctly" given that the template transforms don't get the same babel treatment.
As an alternative, we can also make it possible to pass this option through to
jscodeshift
fromrunTransform
.However, this would require some refactoring/rethinking of
parseTransformArgs
to make it possible, i.e. it's not as simple as adding it to the list, which was the first thing I tried.The main problem is
yargs
parses--no-babel
into{ babel: false }
and the current code does not handle that well. (I think the current code actually already has problems with things like--verbose
.)If, for some reason, it's desirable to keep the babel option on the jscodeshift side working, I can look into doing the work, but given what I said above I personally don't see a good reason to do that.