search

chexiongsheng / puerts_unity_demo

unity demo for puerts
Other
197 stars 80 forks source link

Puerts using Unity package structure #37

Closed marwie closed 2 years ago

marwie commented 2 years ago

Hello,

I started using puerts recently and am really impressed by it!

This PR moves the puerts code into a package. This change has the following benefits:

The structure proposed is what we are using in all of our projects.

The PR does also make the following changes (let me know if you'd want this to be split into separate PRs instead):

You may have a look at the dev branch where I added another Unity project to the same repo using the shared package to work on additional puerts-unity features

marwie commented 2 years ago

Or should this PR maybe made in the Puerts main repo? Is this a change you would consider making? Would be great to get some feedback, I'd love to help if necessary :)

marwie commented 2 years ago

Just noticed that this is one of the planned changes for puerts anyways :) It would also allow publishing puerts to OpenUPM

zombieyang commented 2 years ago

yes, we're planning to do this.

The main problem is: We want to find a place which can easily store both JS and C# code for Developers.

I'm considering use npm as PuerTS's PackageManager. Because everybody knows it is very suitable for JS code. And I think npm package can also store C# code.

For an example. First the PuerTS code will uploaded to npm. When we start a project. install the PuerTS npm package into TsProj directory. Then we can add the TsProj/node_modules/puerts.core to Packages/manifest.json manually or automatically (maybe with npm hooks).

I know a little about OpenUPM. Could it provide a better solution?

marwie commented 2 years ago

You should be able to store javascript code in a similar fasion on OpenUPM / in one or multiple Unity packages (See Special folders/Hidden section) by adding a ~

Regarding npm for C# maybe you can have a look at Keijiro's npm packages - he is uploading all his unity packages to npm also.

Regarding OpenUPM vs npm: not sure if there is a benefit in using either - you might even be able to upload to both (I think OpenUPM is generally only Unity devs so it might just be a preference or target audiency type decision).

Whatever you choose I would prefer if I could install and update puerts from within Unity by using their PackageManager to see available versions and updates right away from within the editor and use the known/best practices flow for working with Unity.

To make that work maybe the package could be structured like so:

package/

I'm wondering: TsProj is not necessary to use puerts but merely used as a demo, right? So should it be even shipped with the package like that? If you want to provide example maybe a better solution would be to include it as a Sample?

zombieyang commented 2 years ago

thanks for your suggestion.

Yes TsProj is a demo and it's not necessary to put into puerts.core package. I think 04_ConsoleRedirect and 03_NodeTSCAndHotReload rather than puerts.core are more suitable for considering the case: 'design a package layout for the packages with both JS and C# code'.

The reason I want to use npm is that some tools like webpack or rollup can easily combine many npm js package(in node_modules) to one js file. With this usage, PuerTS can just load the js file generated by webpack and no need to solve the dependecies in ILoader. If we put JS code into directory with ~, I'll afraid about that developers may spend too much work to write their Loader.

Besides I think we can seperate it to two steps:

  1. put puerts.core to OpenUPM、Unity PackageManager、npm first. Just using the layout you mentioned above. I think it is perfect.
  2. define the package standard layout to make puerts packages (like consoleRedirect or hotreload and so on) easily managed.

this PR can focus on finishing the first step

marwie commented 2 years ago

Btw something related because you mention hot reload and ILoader: in my experiments I have had both Typescript and C# components in one packages (actually even besides each other) and did use a ScriptedImporter for the .ts files to recompile the javascript code on the fly whenever the typescript changed. This allowed me to have hot reload both in editor at edit time as well as at runtime.

Additionally I also added some functionality to export the typescript code on build-time to the StreamingAssets folder and added loaders that handle hot reload in builds. Tested in standalone windows only tho. I guess you have a lot of similar functionality already but maybe still interesting for you as well? It is all in the dev branch here if you're curious (open the projects/Puets_2020_3 project)

zombieyang commented 2 years ago

Sorry I was spent my time for an urgent feature this week. Back to this issue today :).

I've read your ts-sample. It's nice. Do you consider to publish it as a UPM package? I think I can translate a 中文 doc for you after you publish it as a UPM package (I think it's helpful because most of the puerts developer are using 中文 since now)

I made a UPM branch for puerts today. And I need to submit a PR to openupm repository to add my package on it, right? It make me feel a little bit strange.

marwie commented 2 years ago

No worries! :)

Yes, did you add it via this form https://openupm.com/packages/add ? I'd suggest to convert this repository to the package format and then submit it.

One really nice thing about OpenUPM is that you make updates just by adding a new tag to your repo (in a certain format that you have to define in the yaml, e.g. release/1.0.1) so devs can then just pull the new version via Unity's PackageManager :)