Bundled quartz cli
#502
Comments
|
You can do this with the I chose not to publish it as an npm packager because it adds unnecessary friction to configuring Quartz and I wanted the gradient of making customization changes to Quartz as smooth as possible |
I understand and thank you for pointing out to What is the correct workflow then?
|
|
Either cloning or forking work. It ships with an |
Perfect!
I think it should be more visible in the documentation. |
|
Sorry, but given that without npm it doesn't work this makes no sense λ npx quartz build
node:internal/modules/esm/resolve:854
throw new ERR_MODULE_NOT_FOUND(packageName, fileURLToPath(base), null);
^
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'yargs' imported from /home/necauqua/documents/obsidian/quartz/quartz/bootstrap-cli.mjs
at packageResolve (node:internal/modules/esm/resolve:854:9)
at moduleResolve (node:internal/modules/esm/resolve:927:18)
at defaultResolve (node:internal/modules/esm/resolve:1169:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:542:12)
at ModuleLoader.resolve (node:internal/modules/esm/loader:510:25)
at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:239:38)
at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:96:40)
at link (node:internal/modules/esm/module_job:95:36) {
code: 'ERR_MODULE_NOT_FOUND'
}
Node.js v20.18.You have to run If quartz was an npm package, and after you started using it npm went down (the collapse scenario I guess) its copy would still remain in your And if you dislike npm in particular, you can install packages from git with So the part of the philosophy where you have the copy of the source code locally is fulfilled by npm anyway, as JS is not a compiled language - and even then you just can have the sources in the package too, esp. if you do bundling/minification and/or compile TS. The part where you allow developer-inclined people to tinker with it could've been covered by exposing an API so that they can use it by making a package of their own and depending on I guess I can see how having a good API is a lot of work for a slim target audience, but ideally the first consumer of the API is |
Sure, once it happens, we can think about other options then. Until then if it works then don't break it.
feel free to propose something to improve this :) The beauty of open source. Note that we are using our free time to maintain Quartz so if you are displeased with how it works then try to propose something or support the maintainers in general.
If you don't like how it is then you can just not used it. The description stated very clear, Quartz is "opinionated", so this frustration seems out of place. The problem with "exposing API" is that the development friction is actually a lot higher. If something breaks, then the burden lies back to the maintainers, then PR, bugfix, releases, updates (the whole software development cycle ig). As we said this many times before, we don't work on this full time and willingly maintain the library out of our free time. If it is a company product, then sure it makes sense. At the end of the day, this is not our full time job. For libraries, it makes sense because developers can just think in terms of API access. fwiw Quartz, by default is already pretty good for most users. |
|
I was barely frustrated, just voiced a few points, didn't think it was nearly rash enough to bring out "this is voluntary work, be grateful it exists in the first place" guns, lol
Well I'd love to figure out how to make it work from an npm package installed through git, if people are not super-duper against it, sure Among all of the obsidian exporters quartz does seem to be the best one, and I count the paid first-party publish in this 🙃 |
For the current setup where people have to fork or at least clone quartz
this changes nothing - but it allows you to install quartz as a
devDependency via npm and have it actually work.
One real change is switch from `.quartz-cache` to
`node_modules/.cache/quartz` for transpilation results, this is an
artifact from my previous attempts, I guess with this one I can change
it back - but `node_modules/.cache` feels more better imo idk.
edit: OTOH if you want to have quartz be a _completely_ separate binary
(which this also enables I think), having it create a node_modules
folder is weird, so I made a quick hack for that for now.
Example:
```bash
$ mkdir my-repo && cd my-repo
$ npm i quartz@necauqua/quartz#untangled # quartz@ prefix is important
$ cp node_modules/quartz/quartz.*.ts . # copy the default configs
$ mkdir content && echo "# Hello World!" > content/index.md
$ npx quartz build --serve # this just works!
$ echo 'body { background: red !important; }' > styles.scss
```
Notice how I used my branch in the `npm i` line, ideally it'd be
`npm i quartz@jackyzho0/quartz`, or maybe we can somehow get the quartz
package on npm and it'll just be `npm i quartz`.
In the latter case `npx quartz build` will literally just work without
a local npm package at all?.
Having some support for components and plugins being in separate npm
packages instead of people copying code around is not out of the picture
with this too btw.
Closes jackyzha0#502
For the current setup where people have to fork or at least clone quartz
this changes nothing - but it allows you to install quartz as a
devDependency via npm and have it actually work.
One real change is switch from `.quartz-cache` to
`node_modules/.cache/quartz` for transpilation results, this is an
artifact from my previous attempts, I guess with this one I can change
it back - but `node_modules/.cache` feels more better imo idk.
edit: OTOH if you want to have quartz be a _completely_ separate binary
(which this also enables I think), having it create a node_modules
folder is weird, so I made a quick hack for that for now.
Example:
```bash
$ mkdir my-repo && cd my-repo
$ npm i quartz@necauqua/quartz#untangled # quartz@ prefix is important
$ cp node_modules/quartz/quartz.*.ts . # copy the default configs
$ mkdir content && echo "# Hello World!" > content/index.md
$ npx quartz build --serve # this just works!
$ echo 'body { background: red !important; }' > styles.scss
```
Notice how I used my branch in the `npm i` line, ideally it'd be
`npm i quartz@jackyzho0/quartz`, or maybe we can somehow get the quartz
package on npm and it'll just be `npm i quartz`.
In the latter case `npx quartz build` will literally just work without
a local npm package at all?.
Having some support for components and plugins being in separate npm
packages instead of people copying code around is not out of the picture
with this too btw.
Closes jackyzha0#502
For the current setup where people have to fork or at least clone quartz
this changes nothing - but it allows you to install quartz as a
devDependency via npm and have it actually work.
One real change is switch from `.quartz-cache` to
`node_modules/.cache/quartz` for transpilation results, this is an
artifact from my previous attempts, I guess with this one I can change
it back - but `node_modules/.cache` feels more better imo idk.
edit: OTOH if you want to have quartz be a _completely_ separate binary
(which this also enables I think), having it create a node_modules
folder is weird, so I made a quick hack for that for now.
Example:
```bash
$ mkdir my-repo && cd my-repo
$ npm i quartz@necauqua/quartz#untangled # quartz@ prefix is important
$ cp node_modules/quartz/quartz.*.ts . # copy the default configs
$ mkdir content && echo "# Hello World!" > content/index.md
$ npx quartz build --serve # this just works!
$ echo 'body { background: red !important; }' > styles.scss
```
Notice how I used my branch in the `npm i` line, ideally it'd be
`npm i quartz@jackyzho0/quartz`, or maybe we can somehow get the quartz
package on npm and it'll just be `npm i quartz`.
In the latter case `npx quartz build` will literally just work without
a local npm package at all?.
Having some support for components and plugins being in separate npm
packages instead of people copying code around is not out of the picture
with this too btw.
Closes jackyzha0#502
For the current setup where people have to fork or at least clone quartz
this changes nothing - but it allows you to install quartz as a
devDependency via npm and have it actually work.
One real change is switch from `.quartz-cache` to
`node_modules/.cache/quartz` for transpilation results, this is an
artifact from my previous attempts, I guess with this one I can change
it back - but `node_modules/.cache` feels more better imo idk.
edit: OTOH if you want to have quartz be a _completely_ separate binary
(which this also enables I think), having it create a node_modules
folder is weird, so I made a quick hack for that for now.
Example:
```bash
$ mkdir my-repo && cd my-repo
$ npm i quartz@necauqua/quartz#untangled # quartz@ prefix is important
$ cp node_modules/quartz/quartz.*.ts . # copy the default configs
$ mkdir content && echo "# Hello World!" > content/index.md
$ npx quartz build --serve # this just works!
$ echo 'body { background: red !important; }' > styles.scss
```
Notice how I used my branch in the `npm i` line, ideally it'd be
`npm i quartz@jackyzho0/quartz`, or maybe we can somehow get the quartz
package on npm and it'll just be `npm i quartz`.
In the latter case `npx quartz build` will literally just work without
a local npm package at all?.
Having some support for components and plugins being in separate npm
packages instead of people copying code around is not out of the picture
with this too btw.
Closes jackyzha0#502
MOVE ME
Right now in order to make
quartzwork one has to fork the project.It would be great to have a
npmpackage which we can use to buildquartz(something likecreate-react-app).I saw you had something on
npmbut it has been deprecated. Why's that?The text was updated successfully, but these errors were encountered: