Publish a ESM version

[jimmywarting]

1. use explicit path in your import statment (don't forget to use .js at the end.
2. remove all cjs / require() calls
3. add "type": "module" to package.json

[WebReflection]

I have the same issue in polyscript, I need to hack on global to grab the PHP.

That's only the first issue though ... the web or worker are basically unusable right now, not sur ehow PhpWeb solves that but that's another story.

[WebReflection]

To whom it might concern I wanted to play around this and re-packaged this (hopefully temporarily) so that now I can get it working as expected: https://github.com/WebReflection/php#readme

Issues found:

• the printErr is invoked all the time with empty messages
• when errors actually happen these don't pass through any error handler or printErr
• the emscripten FS is missing ... not clear how to fetch and include or require PHP files from the virtual FS
• there is no way to export globals ... but in general there is no FFI to automatically map JS to PHP values and vice-versa
• it's pretty weird one needs <?php as code prefix for run but while it might make sense on JS API when content is in the page and the page is a <?php page itself I think stuff might break badly
• there's no way to run synchronous code, it's always async even if the interpreter is awaited and ready to go

Overall I think this project is cool but it needs a bit more to be easily embedded in polyscript as right now is a bit too primitive/early stage, imho.

[seanmorris]

I've created an ESM version and published it with unpkg as a preview:

https://jsfiddle.net/ohtba1d8/1 (might take a moment to load)

const loadPhp = import('https://www.unpkg.com/[email protected]/PhpWeb.mjs');

loadPhp.then(({PhpWeb}) => {
	
  const php = new PhpWeb;
  
  let buffer = '';
  
  php.addEventListener('output', (event) => buffer += event.detail);
  
  php.addEventListener('error', (event) => {
    	event.detail.forEach(error => {
    	error = error.trim();
    	if(error) console.log(error);
    })
  });
  
  php.addEventListener('ready', () => {
  	document.body.innerHTML = "";
  	buffer = '';
  	php.run('<?php phpinfo();').then(() => {
    	document.body.innerHTML = buffer;
    });
  });
});

[WebReflection]

@seanmorris ... thanks for ignoring my previous effort :sweat_smile: https://github.com/seanmorris/php-wasm/issues/28#issuecomment-1744974580

[seanmorris]

• the printErr is invoked all the time with empty messages
• when errors actually happen these don't pass through any error handler or printErr

I need to look into this and see if its still occurring with the latest refactor, but it looks like errors are treated just the same as normal php.

• the emscripten FS is missing ... not clear how to fetch and include or require PHP files from the virtual FS

I've updated the docs to more clearly explain how to get files preloaded into the FS. I've also added the ability to load files up at runtime.

• there is no way to export globals ... but in general there is no FFI to automatically map JS to PHP values and vice-versa

Vrzno provides an FFI that lets you access any object, function or class in Javascript:

https://github.com/seanmorris/vrzno

• it's pretty weird one needs <?php as code prefix for run but while it might make sense on JS API when content is in the page and the page is a <?php page itself I think stuff might break badly

Perhaps that could be a php.ini setting.

• there's no way to run synchronous code, it's always async even if the interpreter is awaited and ready to go

Is there a use case that demands synchronous code? Does await not fill the gap for you?

The latest version (0.0.9) is currently in alpha.

[WebReflection]

Is there a use case that demands synchronous code?

anything dealing with events on the DOM side, as there's no way to invoke stopPropagation() or preventDefault() in an async way.

By contract, polyscript offers two ways to execute code: run and runAsync. There are already various places where run is preferred over runAsync but there are also cases where async cannot work.

After all, I think with top-level await enabled by default most things would be just fine async too, still the way we orchestrate events dispatching gotta be sync somehow on our side or there is limited cooperation between JS and PHP in some very specific case.

[seanmorris]

@WebReflection Can we move those concerns to a new issue? I'd like to close this one since ESM is going to be the primary release type from now on.