Why limit it to Microsoft services (github and npm)? Why not let it import things from a URL?
Looking forward to your WC2 clone!
Why limit it to Microsoft services (github and npm)? Why not let it import things from a URL?
Looking forward to your WC2 clone!
Not that you're asking, but https://www.littlewargame.com/ is a good WC1/WC2 clone with a lot of good QoL features included.
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.
Thanks!
Actually I am planning on shifting it towards importing '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:// 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:// import specifier.
[1] 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.