-
-
Notifications
You must be signed in to change notification settings - Fork 594
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
ast(parser): command remove #461
Conversation
return this.prompt([ | ||
List( | ||
"actionType", | ||
"What property do you want to remove?", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which would probably be better here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree
Array.from(PROP_TYPES.keys()) | ||
) | ||
]) | ||
.then(actionTypeAnswer => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll need to prompt for sub-props too. Check out how the add generator is built
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in case of removal, sub-props would need webpack config to be read. For instance, in case of plugins
, before we prompt user which plugin he wants to remove, we need to read all plugins from the webpack config file.
In case of add, it works as we prompt all options (or plugins that can be installed) and then the user selects which plugin to install.
If we want to go for sub-prompts then it would need the reading of webpack config file. That's why I've kept it simple for now and removed the key that is selected directly. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you try to impl the read from config? It's quite nice
packages/utils/recursive-parser.js
Outdated
) | ||
.forEach(p => { | ||
if (action === "remove") { | ||
// remove property |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs to be recursive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few missing bits here:
- Check out the
add
generator we have. Do the same, but ask if the user wants to remove some sub-props instead. Build up ayeoman
rc-file based on the current config, but remove parts we've prompted. After doing so, you can just call something similar toutils.addProperty
on the yeoman file, and this would be equivalent to removing a node.
This is rather expensive to do, so it might be better to find the node you're trying to remove and then removing it. That requires you to mark the property in the yeoman file, and it would be cumbersome developer-wise. I'd advise you to do the first mentioned thing.
This means:
- Build a yeoman file.
- Traverse through the ast using a similar method as
utils.addProperty
, but check if the node we're at is present in the yeoman config and in the webpack file. If it is, then we shouldn't do anything. - When we find a node that is in the webpack file, but not in the yo file, remove it.
@dhruvdutt Thanks for your update. I labeled the Pull Request so reviewers will review it again. @ev1stensberg Please review the new changes. |
packages/utils/recursive-parser.js
Outdated
@@ -39,6 +39,9 @@ module.exports = function recursiveTransform(j, ast, key, value, action) { | |||
if (action === "add") { | |||
// update property/replace | |||
j(p).replaceWith(utils.addProperty(j, p, key, value, action)); | |||
} else if (action === "remove") { | |||
// remove property | |||
j(p).remove(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely not enough. Working on AST parser for removal..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is it going? What have you done today?
}); | ||
} | ||
|
||
writing() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this, we can abstract the add generator into a base generator and pass in the name ( action ), and use that instead if the behaviour is the same
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic for removal is quite different and simple. It just keeps on checking type of value
or right-hand part and prompts for removal of keys.
I think there is no common logic between add and remove generator other than saving of yeoman rc file inside writing()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Work on the ast part + review comments
if (typeof propValue === "object") { | ||
if (Array.isArray(propValue)) { | ||
// TODO: handle Array<string>, Array<object> | ||
console.log("TODO: array type node"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBD
]) | ||
.then(({ keyType }) => { | ||
if (propType === "module" && keyType === "rules") { | ||
return this.prompt([ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice1
Let's go for the recursive approach. Feel free to do a benchmark and reopen this if the non-recursive gives better performance. :) |
167599e
to
b9074a8
Compare
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CI:
ERROR: packages/info/index.ts[8, 2]: Calls to 'console.log' are not allowed.
Fix:
Actually, the tslint issue was resolved in another TS PR. Anyway, I've added the same fix to this PR as well. The tests are failing due to other TS related reasons. |
|
||
defineTest( | ||
__dirname, | ||
"remove", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can just do one deep test for remove with multiple props
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach is non-recursive and it doesn't drill down deep inside props.
Recursive drilling is only needed for the creation of nodes.
We do cover every case as demonstrated in the GIF. :)
The tests have to be individual. We can add more tests if needed. I think one-two test for each prop type should be good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just want to see some deep prop removals succeed, like resolve.alias
|
||
/** | ||
* Prints debugging information for webpack issue reporting | ||
*/ | ||
|
||
export default async function info() { | ||
console.log( | ||
process.stdout.write( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this still throwing console error with the rule enabled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it would show the warning. We can decide on one standard convention to follow between console
or process
.
@dhruvdutt you can rebase now and the TS lint fix should be ready :) Next time, please do a cherry-pick |
Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing! Good work here!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A test with a deep property and this is lgtm from me
I've added tests for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm,
What kind of change does this PR introduce?
Feature
Did you add tests for your changes?
No
If relevant, did you update the documentation?
No
Summary
[EDIT] Forgot to show that if there are more than one key in an object, it will keep other keys and if there is only one key in an object then it will delete the whole object.
Does this PR introduce a breaking change?
No
Closes #500