-
-
Notifications
You must be signed in to change notification settings - Fork 86
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
Refactor CLI to use "commands" #33
Comments
I really like this idea! 11ty is a lot simpler than Lume, and Lume is a lot more pluggable and flexible and configurable so I think it is fit that we adopt a more "powerful" CLI system. I think we could use yargs for this. |
I agree this would be better but, f you're going to do this, I think I prefer And one more thing: I think |
Hi. I also agree that And about the
And using fixed versions, this check is done only the first time, then it's cached, so it's a lot faster. If you want to contribute to the work done in this branch, PR are welcome. |
Awesome. Thanks for the quick feedback. Good to see work already being done on this front @oscarotero. I will check out that branch and contribute where I can. |
I just retested this and you're right. A couple of weeks ago, I ran |
@probins Yes, correct. It's a way to ensure that cli.js and mod.js and plugins are using the same version. This is also critical because all these modules share the same cache system. And if they use different versions, they use also different caches. |
an alternative is to have not a config file but a build file. I just created a copy of It's quite common in Node to have a JS API version as well as cli, and this is similar. It removes the need for an installed script, and the problem of updating it. |
The cli api has also Btw, you don't need to copy Anyway, why do you think this is an alternative for the caching issue? |
if I no longer use the installed script, I don't have to upgrade it. I specify directly in the build script which version I want to use, so the dependencies should all be loaded from that version. If I also define the same version for the plugin imports I'm using, any cache problems should go away, right? |
Yes, correct. In fact, Deno recommends to use always versioned imports (I read it, don't remember where). This is what Because the problem is not that the installed version (cli.js) is a different version as the imported modules in _config.js, because the cli code only runs the site instance returned by _config.js. The problem is when the _config.js imports several lume modules from different versions (for example: |
but that's precisely my point: if both the _config.js and the cli define the version no, and the 2 are updated by 2 separate commands, then there is always the chance they will be out of sync. It's also more work for the user. Perhaps Anyway, I'm changing all my configs to include I think this issue can be closed. |
Yes, if you don't need any extra functionality that cli provides (like run scripts, watch, server and live-reload features), it's perfectly fine don't install it. The cli interface is similar to what other node libraries provide in a different package (postcss-cli, webpack-cli, etc). But in Deno, thanks to the ES module, we don't need to create different packages, because if you don't use it, this code won't be downloaded.
Maybe, but |
Closed by #34 |
First, this project is great. Keep up the good work.
This is a proposal for a redesign of the CLI interface. I'd be happy to put in a PR for if it seems like a good thing to do.
A Proposal
Redesign the CLI interface to use "commands" instead of options.
Each command would have its own
--help
output as well, specifying the relevant options for that commandIf this looks like a good direction for lume I can get a PR ready sometime this week
The text was updated successfully, but these errors were encountered: