Comments (13)
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.
from lume.
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.
from lume.
I agree this would be better but, f you're going to do this, I think lume COMMAND [OPTIONS]
would be more logical. The options only apply to some commands, and the help should make this clear. There is also the run
command, and dev
, though I'm not sure what effect this has.
I prefer -v
to -V
(and I wish there was consistency in this across all scripts/systems :-( ). I also think it would be useful if this command (or is it an option?) let the user know if a later version is available. Creating a separate update
command raises another issue. The configuration docs use import lume from "https://deno.land/x/lume/mod.js";
, i.e. always use the latest version. This means that if you have installed lume
and you run it when a newer version is available, it uses the new version, but the installed script is not updated. So, -v
gives you a different version from what is actually used. This needs redesigning, I think.
And one more thing: I think build
should remain the default command.
from lume.
Hi.
Thank you very much to bring this up. Casually, I have been working on a similar change a couple of days ago, in a different branch (https://github.com/lumeland/lume/blob/feature/cli-refactor/cli/help.js). I like the idea of having a --help
option for every command, I don't know if yargs can do that automatically.
I also agree that build
should be the default command, so running lume
or lume build
are equivalent. To me, --serve
is an option of build
.
And about the update
, this is an undocument command that I'm testing because Deno caches the modules forever, so no matter if you install the latest version of lume, if your _config.js
file imports lume without version, it will use the cached version. Until now, I've fixed it by running deno cache
here but this should be used also with all plugins that are not loaded by default (postcss
, terser
, etc), so it's not the ideal situation. Maybe update
is not the most apropiate name, and fix-version
or something like that, is better. In addition to that, I found that deno checks always the types before runing:
lume
Check https://deno.land/x/lume/cli.js
Check file:///Users/oscarotero/my-site/_config.js
...
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.
Thanks!
from lume.
if your
_config.js
file imports lume without version, it will use the cached version
I just retested this and you're right. A couple of weeks ago, I ran lume
(the previously upgraded version, no longer the latest) and it fetched the latest version. I thought this was caused by the config file, but it must have been something else. So what's the use case for having both update and upgrade? Both the config file and the cli are importing mod.js
, so these should surely always use the same version.
from lume.
@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.
from lume.
an alternative is to have not a config file but a build file. I just created a copy of _config.js
with site.build()
at the end instead of export default site
. Then deno run -A --unstable ./_build.js
. Seems to produce the same result. I can set the version in the import of mod.js
, and if I want to use a new or other version of lume, I just change the import in the build file.
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.
from lume.
The cli api has also lume --serve
that not only runs a build but also watch changes and update the site accordingly. Or lume --run
to run a script registered in the site. So this is why _config.js
export the site instance, in order to perform different commands with the same site instance.
Btw, you don't need to copy _config.js
, just import it with import site from "./_config.js"
.
Anyway, why do you think this is an alternative for the caching issue?
from lume.
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?
from lume.
Yes, correct. In fact, Deno recommends to use always versioned imports (I read it, don't remember where). This is what lume --update
does, normalize the imported lume modules in the _config.js file to the same version (it uses the same version of cli but is not required).
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: mod.js
is v0.8.1 and plugins/terser.js
is v0.9.0.
from lume.
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 upgrade
could always run update
.
Anyway, I'm changing all my configs to include site.build()
, and will see if I encounter any problems. I'm also using this kind of process in other Deno systems I'm using, as ISTM it's simpler than maintaining installed scripts.
I think this issue can be closed.
from lume.
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.
Perhaps upgrade could always run update.
Maybe, but update
updates the current _config.js file and you can have several projects with lume.
from lume.
Closed by #34
from lume.
Related Issues (20)
- Lume failse to build/serve with atypical Linux directory structure. HOT 6
- Better path naming convension HOT 8
- Lume serve: expected to respect ServerOptions for location HOT 2
- @std/log not found in registry-staging.deno.com HOT 2
- lume().copy() is a no-op when lume({src: "docs" }) is set HOT 4
- search.pages() return results is zero HOT 2
- How to use "lume-code" and "Tip caution..." in "tailwind typography" HOT 2
- InvalidStateError: readyState not OPEN HOT 1
- Lume fails to import nonexisting cms module HOT 1
- Did `basename` just break `esbuild` plugin? HOT 1
- Merged key in the layouts
- inline plugin types for JSX
- webp asset files corrupted on build HOT 3
- How to include/inline external CSS (npm | cdn)
- Improve performance of some plugins with an internal cache
- search not finding generated pages (doesn't seem to be a renderOrder issue?) HOT 2
- Option to allow case sensitive filenames
- lume -s, Fail to copy file to where the path once was a directory HOT 2
- Images are no longer copied to dest. HOT 7
- buildOrder: make page render after all plugins are run HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lume.