webxdc / hello

Sample project with a simple implementation of the webxdc read and write APIs
The Unlicense
29 stars 7 forks source link

Is this a sample project or a dev tool? #51

Open WofWca opened 10 months ago

WofWca commented 10 months ago

The first couple of lines of README say

https://github.com/webxdc/hello/blob/a42c553ba14045d69e718e11d123d8f3c4a78a2d/README.md?plain=1#L3

But for a sample project this looks a little too convoluted, e.g. the "Limitations" section in README looks unnecessary for a sample project, this sounds more like it applies to the webxdc.js stub dev tool. This makes it look like it's required reading to know how this sample project works, which it isn't. I think sample project must be as short and easy to swallow as possible. We have this in https://docs.webxdc.org/get_started.html#a-simple-example, but I don't know, it looks like we're saying that this is the repo of that simple example.

If it's a dev tool, we shouldn't be regarding it as a sample project in https://docs.webxdc.org/.

I think we need to clearly separate the stub webxdc.js and the sample index.html into different projects (also see "Stop the copy-paste of create-xdc.sh, webxdc.js").

adbenitez commented 10 months ago

we should separate the emulator and typescript types definition to a node package developers can install as dev dependency without copying files manually, and the package could offer a vite plugin to transparently inject webxdc.js file without needing the file copied manually

adbenitez commented 10 months ago

we already have https://www.npmjs.com/package/webxdc-types but it is completely different from webxdc.d.ts in the hello repo, we need to merge webxdc.d.ts to that package

WofWca commented 10 months ago

the package could offer a vite plugin

Idk, it doesn't sounds like a good reason to add Vite, it's just a matter of cp node_modules/webxdc-js-stub/webxdc.js ..

adbenitez commented 10 months ago

the vite plugin is an extra feature the module can provide, you don't need "to add vite" providing a vite plugin is basically exporting a function that does something and users add to their plugin section in vite config, if you/user don't use vite ok just copy the file manually every time and implement your own equivalent of vite plugin thing

r10s commented 10 months ago

I think we need to clearly separate the stub webxdc.js and the sample index.html into different projects

well not sure if splitting into two projects helps here, that may result in a subproject inside hello or so, or forcing some packet manager. both with all its troubles. i am not sure that makes things easier to understand and helps onboarding devs.

i think, "hello" is great as a pattern esp, for ppl that are not familiar with js, packet manager or git tooling, just having very few files that one can start with and understand things. i do not see it as an issue if things are duplicated afterwards, eg. create-xdc.sh needs to be adapted anyways (sure, you can do that with vite and whatnot - but you would have to learn it as well)

so, not against adding other tooling and projects and examples - but we should really keep things simple in hello, no npm, no typescript, no packet manger, no transpiling, no git specials.

as long as we make things simpler in hello, of course, we can adapt here as well. also the README can be improved, for sure

to answer the initial question: it is a sample project that can act as a dev tool :)

WofWca commented 10 months ago

forcing some packet manager

We can make a separate project for the stub webxdc.js while keeping webxdc.js in this project as a copy-pasted file, stating where the file is coming from (see #52), like it sort of is with webxdc.d.ts (see #53).