WickPM

[hobbsythe6th]

WickPM is a package importer class that generates a script tag on the DOM to use to artificially construct esm.sh import statements, which are then attached to WickPM.imports . This PR has attached WickPM, WickPM.imports, and WickPM' s install/uninstall functions to the global API. It's also branched off the Rolldown migration branch of my fork (sorry), but the changed files from that are:
GlobalAPI.js,
WickPM.js,
Wick.mjs (some tiny import updates),
Editor.jsx,
and Project.js .

Read the diff here

[InternetAstronaut]

I don't like the way WickPM works. Firstly, the name WickPM is misleading, it doesn't load scripts or objects made for Wick Editor. Secondly, I'm pretty sure you can just do import from scripts.

[hobbsythe6th]

No, you can't, you get main.381ffc55.js:2 Error: Unexpected token on line 1 in script "default".
at onError (main.381ffc55.js:2:2845680)
at Wick.Project.stop (wickengine.js:51318:47)
at wickengine.js:51234:14
a. @ main.381ffc55.js:2
main.381ffc55.js:2 Error: Unexpected token on line 1 in script "default".
at onError (main.381ffc55.js:2:2845680)
at Wick.Project.stop (wickengine.js:51318:47)
at A_.componentDidUpdate (main.381ffc55.js:2:2845971)
at ca (main.381ffc55.js:2:1372514)
at wl (main.381ffc55.js:2:1390121)
and well you get the idea
from just trying to run import _ from 'https://esm.sh/lodash'; in a script.
As for the name, it just popped into my head before I started so I stuck with it, but I'm open to alternatives.

[InternetAstronaut]

I think it's better to do this as a ScriptAsset (accepting JS files) class which the project runs every single one loaded when starting for the first time. We could also have a ScriptAsset.prototype.run(), which would allow for script assets to be used as mods for games.

[hobbsythe6th]

But then we'd have a MASSIVE boost in file size if we downloaded a lot of NPM packages like the old Wick Engine. My opinion is that script assets are definitely useful, but this would cut down on size if the majority of script assets are from NPM since we only really store the package names.

[InternetAstronaut]

But then we'd have a MASSIVE boost in file size if we downloaded a lot of NPM packages like the old Wick Engine. My opinion is that script assets are definitely useful, but this would cut down on size if the majority of script assets are from NPM since we only really store the package names.

My idea for script assets isn't to import them with the engine, but instead to provide an easy and simple way to run and execute JS code.

I could even say it's better to make the actual 'running scripts' part another dedicated Script class, which would replace the script objects inside Tickable objects.

[hobbsythe6th]

Even so, I still think this is a good feature. Our current code editor doesn't have import {uid} from 'radash' statements or require(), and I don't know any way to do the same with import(). Closest I can think of is using fetch(), but I don't know anything about fetch() anyway

[InternetAstronaut]

Closest I can think of is using fetch(), but I don't know anything about fetch() anyway

Fetch is an async function to do HTTP requests.

fetch('example.com').then(res => {
  if(!res.ok) throw new Error('error'); // error handling should be done properly
}).then(async (res) => {
  const txt = await res.text();

  document.body.innerHTML = txt;
})

[InternetAstronaut]

Even so, I still think this is a good feature. Our current code editor doesn't have import {uid} from 'radash' statements or require(), and I don't know any way to do the same with import(). Closest I can think of is using fetch(), but I don't know anything about fetch() anyway

Another opinion, why should we allow importing libraries? Almost no wick games actually do this, we're just wasting time to simplify things for the 0.0001% of users who use script injection to get matter.js or some vector math library.

[InternetAstronaut]

After looking more into this feature, I believe it should be implemented as a require() function on the GlobalAPI.

[hobbsythe6th]

I'd say a require() would basically be the same thing as this. WickPM's usage would be (I think) like basically every package that you want to install you can put into frame 1's default script and then reuse, whereas I think the only way to share require()d packages between scripts is to require() them in each one, which slows down installation.