Eject command

[matt-gadd]

Our cli commands are meant to make the consumers code config free by internalising the config/config generation into the command itself. Given this, if a user needs more flexibility than the basic setup, we should allow them to "eject" those configs from the cli so they can use as a base for them to build on. This is an idea implemented in create-react-app.

The easiest way to implement this would just be to add an additional function to the command interface named eject, it is then up to the command to dump whatever config it has in files to the project.

Additional thoughts:

• Nearly all eject commands are going to want to add dependencies to the package.json, so we might want to implement a helper to do that.
• dojo eject seems like it should be an internal command to the cli. We don't have the concept of internal commands at the moment.

[tomdye]

Will this need to re-write the index.html to include script tags etc...?

[matt-gadd]

@tomdye no, the webpack config does that anyway (which would still exist on ejection)

[jdonaghue]

@matt-gadd @tomdye After looking at this for a little while I feel like this is a little more complex than it is for create-react-app or enclave-eject. Mostly because the dojo cli is designed to provide for many different commands that can potentially be totally unrelated and are unknown until the cli begins its execution. Whereas with the previous two cli tools, they have knowledge upfront of what all of the configuration is that needs to be ejected.

So that brings me to the following questions:

• Do we want dojo eject to behave somewhat similarly and just eject all configs from all registered commands as a blanket operation?
  • Basically, by discovering each command (as it does now) and then calling into an eject method defined within each command.
• Or should it be more granular and allow for only a certain commands configurations to be ejected based on what is specified when calling dojo eject?
  • If so what should that look like in terms of execution? Something like dojo eject build webpack which would basically call an eject method built into the dojo-cli-build-webpack module?

Either of these make me a little nervous. Mostly because there isn't an overarching control of dependencies within the dojo cli like there is in the other two tools. The other two tools are (somewhat) atomic in nature and as a result don't have the risks for collisions etc that dojo cli does.

What are your thoughts?

[jdonaghue]

One thing we could do to mitigate the risk of collisions is to make each command module not be responsible for its own ejection, but instead just return a collection of configuration/dependencies to the base cli which would then after collecting all of these execute the eject after considering for any potential conflicts.

[agubler]

@jdonaghue I think that eject will be an optional API the commands can choose to implement. dojo-cli will iterate through all registered commands and check if eject is implemented before running. It will be down to the commands to determine what eject means for them.

[jdonaghue]

Thanks @agubler! Thats what I was thinking made the most sense at first, but then I became concerned about the possibility of collisions (one command has similar configuration to another command like webpack.config.js files or something). We would then be putting that responsibility on the commands themselves to analyze for collisions. Instead what I am thinking is that potentially the base cli could execute the eject and the commands are only responsible for telling it what to eject?