Right now there are two ways to start a debug process of a pilet; either a package has been installed (e.g., from an npm registry, or locally etc.) or the path / package can be resolved locally pointing to the raw source code (this is the case in a monorepo). In the latter case running piral debug on it is tried (usually successful, but this may also fail under certain conditions).
I think there is room for at least a third way: Using a website, which may run locally, but usually will run in some kind of (non-production) environment.
The provided environment must have a debug build of the application that also contains relevant parts of the package.json (dependencies / versions) and the declaration. Ideally all relevant parts are put into a special meta.json file, maybe even having an index in there with all used / exposed files.
Background
This is also the way for many single-spa and module federation projects. Quite often this has quite some drawbacks (e.g., more resources needed, local development not so easily possible, ...), but it also can have some advantages (always up-to-date, no need for a private npm registry if none available, ...).
Discussion
The emulator website would mostly be interesting for download purposes. While we could use the website directly, I think having "localhost" for it makes a lot of sense. Some parts definitely need to be downloaded, e.g., the type declarations.
What I imagine would be the best way forward:
In the pilet.json having a remote with an address marker for the emulator website of the respective Piral instance
When the Piral CLI finds such an entry it creates a package in the node_modules using the name of the Piral instance
The created package will contain the (snapshot of the) type declarations and cached / used files
If online these files will be updated regularly (i.e., in the beginning immediately), but if no connection is there / the emulator website is down then the local fallback will be used
This way the emulator is always up-to-date, but the local sources could be used as fallback in case of offline activity.
New Feature Proposal
For more information, see the
CONTRIBUTING
guide.Description
Right now there are two ways to start a debug process of a pilet; either a package has been installed (e.g., from an npm registry, or locally etc.) or the path / package can be resolved locally pointing to the raw source code (this is the case in a monorepo). In the latter case running
piral debug
on it is tried (usually successful, but this may also fail under certain conditions).I think there is room for at least a third way: Using a website, which may run locally, but usually will run in some kind of (non-production) environment.
The provided environment must have a debug build of the application that also contains relevant parts of the package.json (dependencies / versions) and the declaration. Ideally all relevant parts are put into a special meta.json file, maybe even having an index in there with all used / exposed files.
Background
This is also the way for many single-spa and module federation projects. Quite often this has quite some drawbacks (e.g., more resources needed, local development not so easily possible, ...), but it also can have some advantages (always up-to-date, no need for a private npm registry if none available, ...).
Discussion
The emulator website would mostly be interesting for download purposes. While we could use the website directly, I think having "localhost" for it makes a lot of sense. Some parts definitely need to be downloaded, e.g., the type declarations.
What I imagine would be the best way forward:
remote
with an address marker for the emulator website of the respective Piral instanceThis way the emulator is always up-to-date, but the local sources could be used as fallback in case of offline activity.