2 ms·

Why limit it to Microsoft services (github and npm)? Why not let it import things from a URL? Looking forward to your WC2 clone!

by sneak 1y ago

bpshaver 1y ago
Not that you're asking, but https://www.littlewargame.com/ https://www.littlewargame.com/ is a good WC1/WC2 clone with a lot of good QoL features included.
- 90s_dev 1y ago
  Man I wish I was as good at pixel art as those people apparently are! That's part of why I made my app into a platform where you can build apps but also share apps, libraries, and game assets. I can't make a game all on my own! I'm hoping people make and share spritesheets with this, after someone makes a spritemaker app of course. I'll keep working on my basic one.
90s_dev 1y ago
Thanks! Actually I am planning on shifting it towards importing 'https:// https://' URLs directly. Honestly, the main difficulty I have is keeping full TypeScript support of remote modules. It's actually easier to do this if I import https:// https:// modules directly, though it's not as convenient as it could be[1]. But I'm also trying to figure out whether I should continue to compile TSX to JS in the service worker[2], which requires no special dev-time setup and allows publishing raw .tsx files anywhere on the net such as github, or require users to compile TSX -> JS ahead of time, which would require a build step. On top of that, I'm considering going further and making it so packages can import bare-specifiers like `import "somelib"` and publish a plugin to compile this into an https:// https:// import specifier. [1] https://stackoverflow.com/questions/79628025/is-there-a-way-to-alias-an-external-module-without-an-extra-file https://stackoverflow.com/questions/79628025/is-there-a-way-... [2] I currently use a service worker to map imports like `/os/fs/{ghb,npm}/...` to `jsdelivr.net/{gh,npm}/...` and compile them and return with the right content-type.

Why limit it to Microsoft services (github and npm)? Why not let it import things from a URL? Looking forward to your WC2 clone!

by sneak 1y ago

Why limit it to Microsoft services (github and npm)? Why not let it import things from a URL? Looking forward to your WC2 clone!

bpshaver 1y ago

Not that you're asking, but https://www.littlewargame.com/ https://www.littlewargame.com/ is a good WC1/WC2 clone with a lot of good QoL features included.

90s_dev 1y ago
Man I wish I was as good at pixel art as those people apparently are! That's part of why I made my app into a platform where you can build apps but also share apps, libraries, and game assets. I can't make a game all on my own! I'm hoping people make and share spritesheets with this, after someone makes a spritemaker app of course. I'll keep working on my basic one.

90s_dev 1y ago

Thanks! Actually I am planning on shifting it towards importing 'https:// https://' URLs directly. Honestly, the main difficulty I have is keeping full TypeScript support of remote modules. It's actually easier to do this if I import https:// https:// modules directly, though it's not as convenient as it could be[1]. But I'm also trying to figure out whether I should continue to compile TSX to JS in the service worker[2], which requires no special dev-time setup and allows publishing raw .tsx files anywhere on the net such as github, or require users to compile TSX -> JS ahead of time, which would require a build step. On top of that, I'm considering going further and making it so packages can import bare-specifiers like `import "somelib"` and publish a plugin to compile this into an https:// https:// import specifier. [1] https://stackoverflow.com/questions/79628025/is-there-a-way-to-alias-an-external-module-without-an-extra-file https://stackoverflow.com/questions/79628025/is-there-a-way-... [2] I currently use a service worker to map imports like `/os/fs/{ghb,npm}/...` to `jsdelivr.net/{gh,npm}/...` and compile them and return with the right content-type.