TyphonJS•7mo ago

TRL `0.2.0` Release

This is an archived post for the 0.2.0 release that discusses many changes between 0.1.x and 0.2.0. There was a 4 month beta / RC period leading up to the final 0.2.0 release. There is a lot of good information to refer to in this post, so I am not creating an additional post. If you are upgrading still from 0.1.x please refer to information below. --------- Greets @FVTT ▹ Developer, I am starting a new post to discuss / troubleshoot any problems or concerns you might have in regard to updating to the beta build of TRL 0.2.0-next.2 and beyond. The 0.2.x release series of TRL is all about hardening & streamlining the API taking a solid 2nd+ pass over everything. It represents "peak TRL" for Svelte 4. As mentioned it's important to get on 0.2.0 as 0.3.0 will be out ASAP addressing Foundry v13 as early in the core dev release cycle as possible. There are many refinements / sub-path export changes to account for in the 0.2.0 release. I was able to update Automatic Animations (AA) from an really old alpha build of TRL (0.0.23!) in 3 hours. AA is a huge package. I spent another hour adding new 0.2.0 features to AA definitely improving it. See the attached video for more details on what was fixed in 0.2.0-next.2. I realize I didn't put out some release / update notes which will help somewhat in the process. There aren't many breaking changes, but a pertinent one for callbacks. You'll mainly have to watch out for app header buttons and any TJSDialog callbacks as now an object is passed back instead of an argument list. Here is the overview / notes: Package sub-path Changes: - Widely used change: localize is located in #runtime/util/i18n. - All "application shell" components are located in #runtime/svelte/component/application. - Several more sub-paths are refined in the runtime & standard library. Use API docs to find new sub-paths. This package overview page is handy too. Breaking Changes: - Runtime library - SvelteApplication - app header - onPress callback now takes an object { button, event }. To change the button icon / label on press modify button after destructuring. - To define Svelte components set the svelte property to a TJSSvelteConfig object. - SvelteApplication.state method name changes. If you are serializing / storing app positional state you need to update get() to current(). - get() to current() - getSave() to get() - TJSDialog - onClose & onPress callbacks take an object { application } - #runtime/svelte/store/fvtt -> gameState removed; use globalThis.game in templates instead. - All document CRUD dialogs moved to standard library #standard/application/dialog/document - Standard library: - Various components / mostly buttons -> onClickPropagate to clickPropagate - TJSMenu / TJSContextMenu onPress callbacks take an object { event, focusSource, item } --- Refinements: - TJSDocument / TJSDocumentCollection - Improved Foundry callback registration. No need to manually call destroy(). - TJSGameSettings - No longer checks for equality on game setting store update allowing objects to be stored. ------ These are many other refinements, but some of those above were concerns from various developers. Of course the breaking changes to look out for as well. Here is the 0.2.0-next.2 / AA update video: https://www.youtube.com/watch?v=tlaBOCmGBe8

TyphonJS

YouTube

TRL 0.2.0-next.2 Update Marathon #1

Just a brief discussion of 0.2.0-next.2 and confirmation that Automatic Animations (AA) is now current. AA was on TRL 0.0.23 / alpha version of TRL, so besides being a huge package it took me 3 hours to update to 0.2.0-next.1 then an extra hour to add new features from the latest TRL for modal file pickers which is a nice improvement. I a...

85 Replies

TyphonJS (Michael)OP•7mo ago

Also a heads up when using the latest Vite 5.4.10. If you are deploying your repo directly into Data/modules/<MODULE_NAME> using the provided Vite configs from essential-svelte-esm or the template repo that compile to ./index.js in the module path you will see the (!) build.outDir warning. This is to be expected and is OK in this case. svelte-preprocess uses an older JS API for sass. I'm sure this will be updated soon. You can install the latest svelte-preprocess for Svelte 4 & 5. This is what the sass warning refers to, but is fine. The latest is automatically installed as a peer dependency of #runtime.

DavidL•7mo ago

Upgraded, no real issues here. Had to upgrade svelte-preprocess to v6 and change a couple of imports but works fine. I do have a minor issue with typescript not reconginzing the imports for some reason, I added them to the tsconfig as paths but still no dice, it is very minor tho and the code does compile, just an issue in webstorm it seems

TyphonJS (Michael)OP•7mo ago

Right on.. For folks that haven't dug in too deep or that are already on 0.1.x the upgrade shouldn't be too bad. Mostly just changing sub-path exports to more refined paths. The callback changes to an object and not argument list for app header buttons / TJSDialog are a point to watch out for if used. For instance the Automatic Animations PR was deep, but it also was coded at a much earlier point in time and uses more of TRL, so many of the points above in the list of things to watch out for were applied. AA also had problems being a large Handlebars package before conversion to Svelte. It works, but isn't a good example of how to go about things per se; no fault of the original author though. IE a very good MVP that in a professional context would get an architecture overhaul / restructure. Regarding types for anything that touches Foundry like #runtime/svelte/application types are withheld / not hooked up because there are no minimal types for Foundry core API / IE Application and whatever else is referenced that are suitable to hook up. If things were quiet on the Foundry front without a looming need to address v13 immediately I was planning on making a minimal set of Foundry types for just the aspects where TRL touches Foundry, but alas things are not quiet and v13 / 0.3.0 work to adjust to Foundry platform CSS / style changes must commence immediately to get ahead of those changes and give folks using TRL enough time to test packages on v13. Alas I can't tie TRL to the Foundry community types for several reasons despite the effort expended by folks in that area. I will get a types solution in place for those sub-path exports soonish, but alas not likely before v13 concerns are solved and this is mostly due to "unknowns" in Foundry platform changes at this time. As things go first / early Foundry prototype release can also be incomplete / far from finished. The big problem there is that there is no visibility when v13 will be released, so the cautious approach is to drop everything and work on that ASAP. --- What I am working on the next two days is adding as much detail / additional API docs to in the source JSDoc / various sub-path package descriptions. I'm also going to try and get basic architecture overview / programmers guide / getting started resources together and clean up various repo guides / info. Oh hey.... Just noticed some funky bits in the image; IE:

const width = ${window).width() * 0.5;
const height = ${window).height() * 0.5;

const width = ${window).width() * 0.5;
const height = ${window).height() * 0.5;

TRL 0.2.0 is more capable than core AppV1/V2. You can use percentages for width / height data ala

left: '25%',
top: '25%',
width: '50%',
height: '50%',

left: '25%',
top: '25%',
width: '50%',
height: '50%',

Also TRL supports setting minWidth / maxWidth as data values. There are many other handy positional features. I also highly recommend never using JQuery at this point and learning the DOM API. IE window.offsetHeight is the same value. Granted this thread is to support folks upgrading to 0.2.0, but worth mentioning the above.

DavidL•7mo ago

Cool, I remmber trying that a while back and it didnt work so I went with this, I'l give it a try

TyphonJS (Michael)OP•6mo ago

The percentage support is new. The underlying TJSPosition which is what you are working with as SvelteApplication.position vs a bare object in the core API is quite robust / fully reactive positional store + animation / movement validation. I recommend folks check out the App Control / Animation demo in essential-svelte-esm. You can do all sorts of fancy things now like relaitive adjustments: app.position.width = '+=100px' to add 100px to current width or app.position.width = '150%~' to make the width 150% of the current width. Just bumped @typhonjs-fvtt/runtime to 0.2.0-next.3. No changes / fixes to API. I just moved all dependencies to peerDependencies with open forward versioning. This benefits anyone using pnpm though you will need to use pnpm install --legacy-peer-deps. TRL takes advantage of the flat node_modules structure created by NPM to install dependencies like Vite, Svelte, and everything else required as peer dependencies without requiring explicit configuration in a local project package.json. You can now however provide explicit package dependency if desired. ---- I'll be available on Sunday to help out with any potential PRs for folks running into trouble updating to 0.2.0. Unless any problems arise after this weekend I'll be making the final release on Monday. Just to be prudent I figured I'd give just a little more time for anyone to start the update process and report any issues. If you have the time to update this weekend please give it a shot. This is an opportunity to provide any feedback before 0.2.0 ships. It's rock solid now and there are no expected changes before final release.

TyphonJS (Michael)OP•5mo ago

Alright @FVTT ▹ Developer ... The release candidate of TRL 0.2.0 is out and available. There are no further changes expected before 0.2.0 officially goes out the door. This will occur this Friday, but glad to receive any comments before then. I will discuss some of the final refactoring and detailed testing that occurred over the last month. For reference in package.json this is:

{
  "dependencies": {
    "@typhonjs-fvtt/runtime": "^0.2.0-next.5",
    "@typhonjs-fvtt/standard": "^0.2.0-next.3",
  }
}

{
  "dependencies": {
    "@typhonjs-fvtt/runtime": "^0.2.0-next.5",
    "@typhonjs-fvtt/standard": "^0.2.0-next.3",
  }
}

I should note that TRL provides additional resources beyond the base Svelte library for advanced app development. The tools that I use to make the TRL components rock solid are available for you to use as well to make your components resilient. In the video below I go over some of the high level architecture details and behind the scene work that I accomplished with 0.2.0. The goal of 0.2.0 was to harden TRL from bottom to top including all dev tooling used along with API docs. All of this successful... It just took time to get it all done. TRL is well positioned now for the Svelte 5 transition. It's a great idea to install the essential-svelte-esm demo repo: Or the direct package link you can drop in the Foundry package manager: - https://github.com/typhonjs-fvtt-demo/essential-svelte-esm/releases/latest/download/module.json I will be making an official 0.2.0 release video stepping through a lot of those demos. I can say that TRL is 100% bug / issue free. I did detailed testing and there is 1:1 complete identical behavior between Chrome and Firefox including usage of all TRL components in cross-window contexts; IE popping out an app via the PopOut! module. This was no small feat as Firefox is quite demanding in this regard. The high level details are that the entire JS / DOM APIs are completely separate in Firefox for cross-window use cases. TRL does a lot of accessibility / focus management that involves the DOM API. The two key utility classes available are A11yHelper and the new CrossWindow. While TRL is 100% cross-browser / cross-window certified that doesn't mean the custom components you write or any 3rd party Svelte component libraries you may use will work in a cross-window context. One must be intentional in designing for this use case. I also tested a game controller / Rumblepad 2 w/ JoyToKey and there are no problems using TRL w/ game controllers. With all of the final work I did a bit of preparatory refactoring at the architecture level and some small minor adjustments to the standard library. Likely these changes won't affect you, but here they are: - all standard components use enabled as optional state to enable / disable. - ripple / rippleFocus were moved to the base sub-path export #standard/action/animate/composable. Notes about Vite 6.... Well TRL isn't the limiting factor here, but the Svelte 4 plugin for Vite is hard locked to Vite 5. The latest usable version for Svelte 4 is @sveltejs/vite-plugin-svelte at 3.1.2. Also I made some adjustments to the Vite config in essential-svelte-esm as @rollup/plugin-node-resolve is no longer necessary for Vite 5. You will see a warning about the Sass 2 API, but that is a Vite 5 quirk changed in Vite 6. All is fine. This was a very long year of lots of grind from bottom to top and it has been a complete success and positions TRL in a position of strength to successfully transition to Svelte 5 as well as deal with the upcoming Foundry v13 style / CSS changes. While the Svelte 5 transition will again be a slowish period once it's complete the sky is the limit https://www.youtube.com/watch?v=CY9aedjx7X8

TyphonJS

YouTube

TRL 0.2.0 Update Marathon #2 Release Candidate

Hey folks.. Just an impromptu video showing off the last month of extreme hardening of TRL and the standard component library including a high level architecture overview. I can now say that TRL is 100% rock solid across Chrome & Firefox not only in the main browser window, but also cross window when using the PopOut! module. It took a bunch o...

Phenomen•5mo ago

Looking forward to Svelte 5 to start some development with TRL. I migrated all my corporate tools and websites to Svelte 5 last month and it was painful, rewriting 50% of the code to runes with barebones documentation and basically no examples / real world projects. But now that I understand Svelte 5 much better, it feels amazing to use, and I just can't downgrade to Svelte 4 for Foundry dev.

TyphonJS (Michael)OP•5mo ago

it was painful

I'm indeed concerned about this regarding folks currently using TRL / Svelte 4 on Foundry. I don't think folks realize how large / actual paradigm shift that it will be. The API surface of TRL will change certainly at the component level and folks that have serious / supported Foundry packages using TRL will have a lot of work to do despite whatever I can do on the TRL side to make things easier. There already is some pretty clear attrition between folks either leaving Foundry dev or just not interested in TRL anymore or simply stopped by temporarily to check things out, but never got started. Getting pinned between the AppV2 Foundry side and Svelte 5 is a "double whammy" so to speak. Svelte 5 still comes across as beta to me with non-stop fixes coming in daily and the whole WAAPI transition system has something like 60 issues that simply aren't being worked on yet. Getting through this transition I'm sure Svelte 6 will be grand.. ;P Additionally, with stock AppV2 just not being suitable for reactive frameworks despite claims, but communicating that is practically impossible on the main forums and hopefully there isn't too much confusion in discussion here. Svelte 5 will give tremendous capabilities at the TRL / framework level though; just lots of busy work until it comes to be. TRL will emerge through all of this strong in time. I truly believe that once reactive property field access is realized with TJSDocument that this opens up the real power of reactivity on Foundry and it will change everything especially for game system devs.

Phenomen•5mo ago

Svelte 5 still comes across as beta to me with non-stop fixes coming in daily

That's absolutely true, they have the whole Advent of Svelte going on right now with new features announced daily https://svelte.dev/blog/advent-of-svelte There are some things that I really want to see, in particular: 1) async version of $effect i.e $asyncEffect. Using async functions in effects this way is not correct because an async function returns a promise that Svelte doesn’t expect and can’t resolve:

  $effect(async () => {
    await sleep(1000);
    return () => console.log('hello') //will never return
  })

  $effect(async () => {
    await sleep(1000);
    return () => console.log('hello') //will never return
  })

So you need to either make it thenable

 $effect(() => {
    sleep(1000).then(() => {
      console.log('hello')
    })
  })

 $effect(() => {
    sleep(1000).then(() => {
      console.log('hello')
    })
  })

Or use immeadiate function like this:

 $effect(() => {
    (async () {
      await sleep(1000)
      console.log('hello')
    })()
  })

 $effect(() => {
    (async () {
      await sleep(1000)
      console.log('hello')
    })()
  })

2) Partial track on $effect, so it will only trigger on changes I want to track, not every single variable in the function. Currently, it can be achieved with runed/watch 3) Reactive context without classes, getters and setters. Not a big deal but it just counter-intuitive that $state doesn't work in context without boilerplate code.

TyphonJS (Michael)OP•5mo ago

I've always been somewhat amazed and personally bummed (because I'm "old school" and announce after engineering is complete) at the new school announcement and hype cycle stoked by Rich Harris and co. The pendulum is finally swinging back around where "announce early / over promise" is thoroughly hitting them in the rear.. ;P The whole announce early to grab tech cred / headlines has a whole lot more to do with marketing than it does engineering. Re: #3: While there is a lot of power with $state when it comes to actually passing state between sources one now has to mindful of pattern construction issues. There is a lot of flexibility, but when it comes to creating a generic data source that can be shared and hooked up with generic components accepting data sources this likely requires following a very specific pattern vs a standard contract (stores). It moves the burden heavily towards sticking with a specific pattern of data construction that can be utilized by generic components that also follow that pattern. At least this is something I'll be paying attention to on the difference between stores and $state.

Phenomen•5mo ago

I mean it's trivial to make it work, I just think it's something Svelte compiler should do automatically without boilerplate.

//that's what I use since I also add utility functions like `reset` and `undo` to classes
class Foo {
    value = $state('bar')
}

setContext('foo', { foo: new Foo() })

//that's what I use since I also add utility functions like `reset` and `undo` to classes
class Foo {
    value = $state('bar')
}

setContext('foo', { foo: new Foo() })

//more straight-forward version with accesors
let foo = $state('bar')

setContext('foo', {
    get foo() { return foo },
    set foo(value) { foo = value },
})

//more straight-forward version with accesors
let foo = $state('bar')

setContext('foo', {
    get foo() { return foo },
    set foo(value) { foo = value },
})

TyphonJS (Michael)OP•5mo ago

Indeed. Svelte 6 FTW. I think we'll see a long continued dev cycle for the nearly the entire Svelte 5 timeframe. It'll be fantastic eventually. I guess what I was hinting at not specifically the use case you mentioned is that passing stateful classes like Foo is not clear cut. I have yet to explore deeper, but I don't think you'll be able to pass foo.value or other properties IE foo.bar as a generic stateful props. I'm going to be looking into creating reactive data classes for all of the TRL components... It's just not clear right now if you have a generic data source like foo.bar that you can assign it to the data source field of the TRL component data class. IE with stores there is a defined API contract on receiving / setting the data. Well.. We are getting off into Svelte 5 / random chat... Definitely want to leave this thread / forum post for any feedback on the TRL 0.2.0 release. Lots to ponder in the near future re: Svelte 5! Also glad that you are diving into Svelte 5 separately. I'm sure it'll be nice to have folks with some experience around when it comes to honing the TRL Svelte 5 experience!

Vauxs•5mo ago

I will say though, working on Svelte 5 from scratch on new websites it makes previous versions syntax almost unreadable now. I have to keep reminding myself that let makes things reactive just bcuz

TyphonJS (Michael)OP•5mo ago

I know I mentioned not using this forum post regarding forlorn remembrances of magic past. Really that was just so folks see the above RC / video announcement, but likely those still interested have done so. One thing I'll miss a bunch is the on:pointerdown|preventDefault|capture event modifiers. While there is some benefit of passing around props for event handlers IE onpointerdown, magic and code brevity is lost. I also have a ton of custom events in TRL that are like close:popup which I assume need to be changed as on:close:popup will no longer be valid as onclose:popup.

Syrious•5mo ago

<script lang="ts">
    import { ApplicationShell }   from '#runtime/svelte/component/application';

    export let elementRoot;
</script>

<svelte:options accessors={true}/>

<ApplicationShell bind:elementRoot>
    <main>
        <h1>Basic application</h1>
    </main>
</ApplicationShell>

<script lang="ts">
    import { ApplicationShell }   from '#runtime/svelte/component/application';

    export let elementRoot;
</script>

<svelte:options accessors={true}/>

<ApplicationShell bind:elementRoot>
    <main>
        <h1>Basic application</h1>
    </main>
</ApplicationShell>

Using <script lang="ts"> no longer works with this version? Error: "ApplicationShell is not defined"

TyphonJS (Michael)OP•5mo ago

I would suggest doing a clean install of Node packages. One way is just deleting node_modules & package-lock.json. I made a lot of things peer dependencies of the runtime package. If you are using NPM then things should work. svelte-preprocess also lists typescript as an optional dependency, so I'd add typescript to devDependencies. I won't be able to test things until Sunday. Where is that error coming from? Does it occur without lang="ts"? This likely is a configuration issue and nothing with TRL per se. If you are taking the straight template-svelte-esm to enable typescript might be as simple as adding it as a package to install; that template covers ESM, etc.

Syrious•5mo ago

I checked out template-svelte-esm added <script lang="ts" the the BaseAppShell and "typescript": "^5.4.5", to devDependencies. Then I run npm install and started vite dev

Vauxs•5mo ago

Try using the package instead of #runtime

TyphonJS (Michael)OP•5mo ago

I assume you have a recent Node version installed. v18+ You should see a warning otherwise. Perhaps run npm run build to build the normal artifacts first then npm run dev. Also try the build and not the dev server straight out. Restart your Foundry server after the initial build. You can also check the modules section on the admin side to make sure Foundry sees it. Where are you seeing the error? In the browser console or during the build process? I assume the latter, but perhaps you can include the output where the error is occurring.

TyphonJS (Michael)OP•5mo ago

This has nothing to do at all with TRL / building / or running the module. The build should have produced information detailing aspects of TS hookup required. Maybe you didn't see this when running npm run dev, but it is present in npm run build. verbatimModuleSyntax is required to be true in any associated tsconfig.json which you should also add. This is a requirement of Svelte / svelte-preprocess. So not a TRL problem per se. It is true that I haven't been able to thoroughly go through all of the Svelte components to explicitly type props and such; several will be typed as any, but the declarations are there. The time investment to thoroughly type all of the Svelte components is a bit moot given how much Svelte 5 is going to change things. I'd rather do a thorough job once instead of twice. Unless you are a TS expert too you should be forewarned that using Typescript w/ Foundry in general is a really mixed bag and you should be ready for headaches.

Syrious•5mo ago

Thanks. That works for me. I already tried verbatimModuleSyntax before but instead of a build I just started the dev server.

Unless you are a TS expert too you should be forewarned that using Typescript w/ Foundry in general is a really mixed bag and you should be ready for headaches.

Coming from a backend developer background for large enterprise applications where clean code is everything it feels just wrong not to have types 😅

TyphonJS (Michael)OP•5mo ago

There will be a few things to tidy up and improve in TRL An awful lot of time has been expended in this area otherwise the API docs wouldn't be in the state that they are presently. The Foundry side will remain problematic.

Syrious•5mo ago

I actually write all the types I need myself. But we are getting off topic. I really appreciate the help. I'll now try to convert my actual module to the new version.

TyphonJS (Michael)OP•5mo ago

If anything comes up / needs clarification feel free to reach out.

geoidesic•4mo ago

Which version of svelte should I have installed?

Vauxs•4mo ago

^4

geoidesic•4mo ago

I seem to be unable to resolve this error when trying to upgrade:

error during build:
[vite-plugin-svelte] [plugin vite-plugin-svelte] Unrecognized option 'hmr'
file: /Users/me/code/foundryvtt-final-fantasy/src/components/organisms/dialogs/ModifierDialog.svelte
Error: [plugin vite-plugin-svelte] Unrecognized option 'hmr'
    at file:///Users/me/code/foundryvtt-final-fantasy/node_modules/svelte/src/compiler/compile/index.js:65:10
    at Array.forEach (<anonymous>)
    at validate_options (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/svelte/src/compiler/compile/index.js:60:23)
    at Module.compile (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/svelte/src/compiler/compile/index.js:134:2)
    at compileSvelte (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/@sveltejs/vite-plugin-svelte/src/utils/compile.js:135:22)
    at async Object.transform (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/@sveltejs/vite-plugin-svelte/src/index.js:164:20)
    at async transform (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:19787:16)
    at async ModuleLoader.addModuleSource (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:20003:36)

error during build:
[vite-plugin-svelte] [plugin vite-plugin-svelte] Unrecognized option 'hmr'
file: /Users/me/code/foundryvtt-final-fantasy/src/components/organisms/dialogs/ModifierDialog.svelte
Error: [plugin vite-plugin-svelte] Unrecognized option 'hmr'
    at file:///Users/me/code/foundryvtt-final-fantasy/node_modules/svelte/src/compiler/compile/index.js:65:10
    at Array.forEach (<anonymous>)
    at validate_options (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/svelte/src/compiler/compile/index.js:60:23)
    at Module.compile (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/svelte/src/compiler/compile/index.js:134:2)
    at compileSvelte (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/@sveltejs/vite-plugin-svelte/src/utils/compile.js:135:22)
    at async Object.transform (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/@sveltejs/vite-plugin-svelte/src/index.js:164:20)
    at async transform (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:19787:16)
    at async ModuleLoader.addModuleSource (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:20003:36)

Vauxs•4mo ago

Upgrade to what? And show the code in question since it clearly says "unrecognized option hmr"

geoidesic•4mo ago

Upgrade from TRL 0.1.3 to 0.2.0-nex.x. I know what the error says – my understanding is that it's talking about vite.config.mjs, but my vite.config.mjs doesn't include that option. In fact hmr doesn't appear in my codebase at all.

Vauxs•4mo ago

Its not though, its talking about ModifierDialog.svelte :thonkang:

geoidesic•4mo ago

I know but that file doesn't include the text hmr either.

Vauxs•4mo ago

what version of vite-plugin-svelte are you on?

geoidesic•4mo ago

5.0.3 And vite 6.x

Vauxs•4mo ago

🙃 All of those are Svelte 5 only

geoidesic•4mo ago

Aha, ok tx

Vauxs•4mo ago

Use

"@sveltejs/vite-plugin-svelte": "^3.1.2",
"vite": "^5.0.0",

"@sveltejs/vite-plugin-svelte": "^3.1.2",
"vite": "^5.0.0",

as far as I am aware at least, those are the last versions you can use

geoidesic•4mo ago

Are these package.json imports invalid?

  "imports": {
    "#runtime/*": "@typhonjs-fvtt/runtime/*",
    "#standard/*": "@typhonjs-fvtt/svelte-standard/*"
  },

  "imports": {
    "#runtime/*": "@typhonjs-fvtt/runtime/*",
    "#standard/*": "@typhonjs-fvtt/svelte-standard/*"
  },

Vauxs•4mo ago

its correct

geoidesic•4mo ago

I thought @typhonjs-fvtt/svelte-standard/ should change to @typhonjs-fvtt/standard/ maybe.

Vauxs•4mo ago

right, it should

    "imports": {
        "#runtime/*": "@typhonjs-fvtt/runtime/*",
        "#standard/*": "@typhonjs-fvtt/standard/*"
    },

    "imports": {
        "#runtime/*": "@typhonjs-fvtt/runtime/*",
        "#standard/*": "@typhonjs-fvtt/standard/*"
    },

geoidesic•4mo ago

Any clue about this one?

[commonjs--resolver] Missing "./svelte/helper" specifier in "@typhonjs-fvtt/runtime" package
error during build:
Error: Missing "./svelte/helper" specifier in "@typhonjs-fvtt/runtime" package
    at e (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:21818:25)
    at n (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:21818:627)
    at o (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:21818:1297)
    at resolveExportsOrImports (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:29071:20)
    at resolveDeepImport (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:29090:31)
    at tryNodeResolve (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:28815:20)
    at Object.resolveId (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:28571:28)
    at file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:20936:40
    at async PluginDriver.hookFirstAndGetPlugin (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:20836:28)
    at async resolveId (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:19440:26)

[commonjs--resolver] Missing "./svelte/helper" specifier in "@typhonjs-fvtt/runtime" package
error during build:
Error: Missing "./svelte/helper" specifier in "@typhonjs-fvtt/runtime" package
    at e (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:21818:25)
    at n (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:21818:627)
    at o (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:21818:1297)
    at resolveExportsOrImports (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:29071:20)
    at resolveDeepImport (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:29090:31)
    at tryNodeResolve (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:28815:20)
    at Object.resolveId (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/vite/dist/node/chunks/dep-4RECYSE1.js:28571:28)
    at file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:20936:40
    at async PluginDriver.hookFirstAndGetPlugin (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:20836:28)
    at async resolveId (file:///Users/me/code/foundryvtt-final-fantasy/node_modules/rollup/dist/es/shared/node-entry.js:19440:26)

I searched for svelte/helpers in my codebase and it doesn't occur there, so I'm guessing it's some package.json mismatch.

  "imports": {
    "#runtime/*": "@typhonjs-fvtt/runtime/*",
    "#standard/*": "@typhonjs-fvtt/standard/*"
  },
  "dependencies": {
    "@sveltejs/vite-plugin-svelte": "3.1.2",
    "@typhonjs-fvtt/runtime": "0.2.0-next.2",
    "@typhonjs-fvtt/standard": "0.2.0-next.2",
    "lodash": "^4.17.21",
    "set-manipulator": "^0.3.1",
    "svelte": "4.2.19",
    "svelte-multiselect": "^10.0.0",
    "svelte-preprocess": "6.0.3",
    "tippy.js": "^6.3.7",
    "uuid": "^9.0.0",
    "vite": "5.0.4"
  },
  "devDependencies": {
    "@foundryvtt/foundryvtt-cli": "^1.0.3",
    "@league-of-foundry-developers/foundry-vtt-types": "^9.280.0",
    "@typhonjs-config/eslint-config": "^0.6.3",
    "@typhonjs-fvtt/eslint-config-foundry.js": "^0.8.0",
    "eslint": "^8.44.0",
    "eslint-config-google": "^0.14.0",
    "prettier": "^3.0.0",
    "pug": "^3.0.2",
    "typescript": "^5.2.2",
    "vitest": "^0.34.3",
    "vitest-fetch-mock": "^0.2.2"
  },

  "imports": {
    "#runtime/*": "@typhonjs-fvtt/runtime/*",
    "#standard/*": "@typhonjs-fvtt/standard/*"
  },
  "dependencies": {
    "@sveltejs/vite-plugin-svelte": "3.1.2",
    "@typhonjs-fvtt/runtime": "0.2.0-next.2",
    "@typhonjs-fvtt/standard": "0.2.0-next.2",
    "lodash": "^4.17.21",
    "set-manipulator": "^0.3.1",
    "svelte": "4.2.19",
    "svelte-multiselect": "^10.0.0",
    "svelte-preprocess": "6.0.3",
    "tippy.js": "^6.3.7",
    "uuid": "^9.0.0",
    "vite": "5.0.4"
  },
  "devDependencies": {
    "@foundryvtt/foundryvtt-cli": "^1.0.3",
    "@league-of-foundry-developers/foundry-vtt-types": "^9.280.0",
    "@typhonjs-config/eslint-config": "^0.6.3",
    "@typhonjs-fvtt/eslint-config-foundry.js": "^0.8.0",
    "eslint": "^8.44.0",
    "eslint-config-google": "^0.14.0",
    "prettier": "^3.0.0",
    "pug": "^3.0.2",
    "typescript": "^5.2.2",
    "vitest": "^0.34.3",
    "vitest-fetch-mock": "^0.2.2"
  },

Vauxs•4mo ago

If you are upgrading, you might as well upgrade to latest TJS and that may solve your issue Because we are past next.2

        "@typhonjs-fvtt/runtime": "^0.2.0-next.5",
        "@typhonjs-fvtt/standard": "^0.2.0-next.3"

        "@typhonjs-fvtt/runtime": "^0.2.0-next.5",
        "@typhonjs-fvtt/standard": "^0.2.0-next.3"

by this point I am gonna put this here since it works https://github.com/MrVauxs/pf2e-graphics/blob/main/package.json

TyphonJS (Michael)OP•4mo ago

You should use production builds while you work through the upgrade refactoring. Read the first message above in this thread because it details the main points to watch out for including the moving of localize from "svelte/helper". You have been through Foundry core refactoring between versions. This is similar though in the case of TRL the refactoring is mainly where things are located and not a change in functionality though there are a few changes to note again in the first post above. Use the API docs looking up symbols that can't be found. The latest versions are next.6 for the runtime library and next.3 for the standard library. I am putting out what I hope is the last "beta / RC" releases on next.7 / next.4 hopefully later today. Next week 0.2.0 final release should be out. Just giving folks a heads up [email protected] and [email protected] is out. Now with rather comprehensive TypeScript support for both the PF2E and League types. There are now two template repos for TS: - template-svelte-ts-league - template-svelte-ts-pf2e The shim layer to generically support multiple sets of Foundry types worked out. There should be comprehensive support including TJSDocument / embedded collection reducers and in the standard library all of the C(R)UD dialogs to work with documents. Also regarding TJSDocument & TJSDocumentCollection the data passed through to subscribers is now normalized to action and data where data will always be an array. Foundry itself will send over a string or object in single document operations and arrays of the same with multiple doc ops. Normalizing the output to always produce an array helps to simplify downstream processing. Chances are no one is using this functionality, but worth noting as technically it's a breaking change though significantly better than receiving action sometimes and renderContext (v12 change) at other times. For those that already have set up TS repos with the previous release take a look at your template repo of choice as there is now a types entry that you need to add for the shim layer. I also have updated the ESM repos / Vite configs to output production builds to /dist, so there are some config mods that you might find useful. ----- From here I have a few more odds and ends to wrap up and hope to make the 0.2.0 final release on the upcoming Wednesday. If folks can hit this hard especially any TS devs that would be handy. I don't expect issues, but the template repos and my spot checking only covered only the most complex new types support. There are several cool new features / type checking against Svelte props / context values and more in any TJSSvelte.Config you provide. ----- I'm exhausted and will make a video & ping tomorrow. Just want to give folks especially in different time zones an early weekend heads up. Thanks for taking a look if you can...

Vauxs•4mo ago

Just tested and the only hitch so far I had was changing the types of Header buttons, nothing too major

Vauxs•4mo ago

Oh and this I guess

Vauxs•4mo ago

Looks like it has to be Partial'd but hey VSCode no longer complains about that comment above! For now just gonna typecast it as as ConstructorParameters<typeof TJSDialog>[1]

geoidesic•4mo ago

I upgraded to next.5 / next.3. Took a day but all working.

TyphonJS (Michael)OP•4mo ago

OK... [email protected] is out. I fixed the SvelteApp.Options types issue. The problem was that when extending the ApplicationOptions interface of the PF2E / League types I didn't use Partial<ApplicationOptions>. The template repos are adjusted slightly to remove the necessity of using Partial in defaultOptions now. For those using TS please hit next.8 and next.4 hard to find any remaining declaration aspects that you'd like to see adjusted / fixed before the 0.2.0 final release next week. --- I have spot checked many of the more advanced TS types support added. The one downside currently is that there isn't a comprehensive TS demo repo like essential-svelte-esm that uses a wide range of the TRL API for type declaration verification. The API docs are solid and it all should work fine, but eventually it will be nice to have a standard demo / reference TS repo that covers a wide range of the TRL API. So yes, if you have a complex TRL package report anything that you think might need a fix. Upgrade to next.8 / next.4. There shouldn't be refactoring for this update.

Vauxs•4mo ago

Updated, all is well.

TyphonJS (Michael)OP•2mo ago

Just to keep folks updated. I've been continuing to work through various areas of TRL converting certain sub-path exports to TypeScript that benefit from stronger and more accurate typing than what is possible from JSDoc. This current round took a bit longer, but the results are fantastic especially for those working with TS. TJSGameSettings and the additional array-object reducers are now strongly typed. IE these sub-path exports:

#runtime/svelte/store/reducer/array-object
#runtime/svelte/store/fvtt/settings
#runtime/svelte/store/fvtt/settings/world

#runtime/svelte/store/reducer/array-object
#runtime/svelte/store/fvtt/settings
#runtime/svelte/store/fvtt/settings/world

To not commit the cardinal sin of making a release before the weekend of which I won't be available for most of it I'll be delaying the next release until ~Monday evening or thereabout. This will make TRL mostly fully covered with thorough typing. It's not like these areas didn't have types before, but in particular for the additional array reducers things things are now verified with A+ typing. I have a few other backend updates to make beyond that, but really want to wrap up the official 0.2.0 release ASAP to get started on v13 compatibility. Greets @FVTT ▹ Developer! The likely final release candidate / RC of TRL 0.2.0 is available now: - [email protected] - [email protected] A lot of the work through January involved tightening up precise type declarations across TRL converting various sub-path exports to Typescript as necessary to get just a bit of extra control that JSDoc + TS can't deliver currently. I highly recommend that any of you that have active packages using TRL update to this RC release as this is a final chance to raise any concerns before the final 0.2.0 release. Of course I can always make patch releases to 0.2.x, but I'm going to be immediately switching to 0.3.0 and working on Foundry v13 compatibility. If you are on an older TRL 0.1.x release and have not updated yet there will be some minor refactoring involved. See the first post in this thread or raise any questions that you might have. If you update to 0.2.0 my goal is to handle the v13 / 0.3.0 update in a way that won't cause any TRL API changes. It's not clear yet whether I'll have to introduce a new Vite plugin to handle any of the v13 CSS layers aspects. ---------- Latest API changes: WorldSettingArrayStore is renamed to WorldArrayObjectStore from #runtime/svelte/store/fvtt/settings/world. Automatic Animations was a main consumer here and already is updated. Not sure if any other packages is using this TRL feature. It's neat.. 😉 The additional array-object reducers are now all strongly typed for those using TS. TJSGameSettings / TJSGameSettingsWithUI are now strongly typed. Deprecated (until 0.4.0): SvelteApplication is renamed to SvelteApp. SvelteApp is re-exported as SvelteApplication, but I don't think there is a way to mark a re-export as deprecated. If you are using SvelteApplication consider changing it to SvelteApp. The re-export will be removed in 0.4.0. Your code will not break if you keep using SvelteApplication, but will in 0.4.0. The reason for the name change is that this shortens the class name. In the type declaration work there is now a namespace with additional types of the same name. This just makes it more convenient to use / less space for those using TS. ---------- Reminder: There has been updates to all Vite configs in the demo / template repos to fine tune DX just a bit more. You may very well want to examine the Vite config for changes. The biggest change is being able to have build assets automatically named by the package ID in the respective package manifest and output to a dist/ folder. Hopefully, somewhat soon I'll get an official TRL CLI out that will make manual management of the Vite config a thing of the past. ---------- All demo repos are updated with the latest release. essential-svelte-esm template-svelte-esm and the TypeScript template repos: template-svelte-ts-pf2e template-svelte-ts-league Greets @FVTT ▹ Developer, TRL 0.2.0 is finally officially out. I am exhausted and won't have time to make a release video today. On a whim I'm taking this small window I have and hitting the mountains for some ski practice this week. This is something that I didn't really get to do last winter as I made TRL a priority. TRL 0.2.0 is a culmination of ~1.2 years of work considerably hardening and refining the API surface / features and all backing tooling behind TRL extending into contributions to other 3rd party OSS that TRL depends upon. It's this maintenance and hardening that makes TRL rock solid. This release is "peak Svelte 4".... There is a lot more work ahead. ---- 0.3.0 will only focus on Foundry v13 support for the new CSS layers changes. You are strongly encouraged to upgrade to 0.2.0 now if you want to release your package for v13. There should be minimal API changes, but you'll need to make a new release w/ 0.3.0 for v13. I'm going to do my best to get this done ASAP. ---- Some of the recent work is fully flushed out TypeScript support for the PF2E & League community types in addition to honing type support in TRL. In between the last RC release and now there were significant changes to the #runtime/util/object sub-path export. I thoroughly cleaned up and optimized this code and everything is very useful for JS / TS use cases in regard to type guards and type inference. There is not much chance that folks are using the functions that were dropped or likely using this package at all. It's used internally to TRL, but available for all. In particular deepMerge is super handy. It's like a deep Object.assign with type inference and works better than foundry.util.mergeObject in that regard for JS & TS. You'll notice all of the demo code for defaultOptions merging is now using deepMerge. So, just do a search in your codebase if you use #runtime/util/object just in case. I don't think many of you are using it yet, but this is a handy package. Just a note: a minor patch fix went out for the standard library 0.2.1 that fixes a rare edge case that most won't hit. The modal file picker support now is guaranteed to work for users under heavy load / many active modules. I only received one user report of this occurring and indeed they ran many modules. Just a note for those following this post. TRL 0.2.x should be rock solid. Please do update to it as 0.3.0 will be coming out with minimal API changes soon to address Foundry v13 core platform changes.

geoidesic•2mo ago

Hi. I tried updating to 0.2.0 today – ended up with a deep cascade of missing dependencies which @typhonjs-fvtt/runtime seems to expect. E.g.

error during build:
[commonjs--resolver] Missing "./svelte/component/core" specifier in "@typhonjs-fvtt/runtime" package

% yarn list --pattern typhon
yarn list v1.22.22
├─ @typhonjs-fvtt/[email protected]
└─ @typhonjs-fvtt/[email protected]

error during build:
[commonjs--resolver] Missing "./svelte/component/core" specifier in "@typhonjs-fvtt/runtime" package

% yarn list --pattern typhon
yarn list v1.22.22
├─ @typhonjs-fvtt/[email protected]
└─ @typhonjs-fvtt/[email protected]

Am I doing it wrong?

TyphonJS (Michael)OP•2mo ago

#runtime/svelte/component/core is now #runtime/svelte/component/application

david aka claudekennilol•3w ago

It looks like by default it's configured to use a dist dir instead of its own root dir which is a great improvement 👍

TyphonJS (Michael)OP•3w ago

Yes. Vauxs contributed some Vite config changes that are handy. So good to check out the example repos.

david aka claudekennilol•3w ago

I'm confused about the expected workflow for running dev

7 ... or dev to run in developer mode which uses esbuild & HMR (hot module replacement) to dynamically update your running module in real time for all Svelte related components. 8. Restart Foundry VTT. This is necessary for Foundry to load the new module. 9. You should now have a new module installed Template Svelte (ESM) or whatever title you set in step #4 visible in your modules list.

So step for step 8 I kill my foundry node service and restart it, but the vite build process doesn't seem to like that (nor does it recover) :30001 just becomes unresponsive

Vauxs•3w ago

You install deps, build the module, then run npm run dev with Foundry open. That's all.

david aka claudekennilol•3w ago

So then what is step 8?

Vauxs•3w ago

Presumably restarting Foundry after building the module so the module gets detected. But you can just enter a world and then back to admin to have more or less the same effect. Regardless, restarting Foundry is not part of the dev process Just the initial "setup" if anything (Wouldn't need any setup if TJS wanted, but that PR was rejected in favor of the end-developer doing it 😛 )

david aka claudekennilol•3w ago

Well then I'm not sure what I'm missing here. Can someone take a look at my vite config? https://github.com/dmrickey/ckl-advanced-templates-pf1/blob/pf1_v11/vite.config.mjs Oh it looks like module.json is pointing to dist/<id>.js now? That's probably it

Vauxs•3w ago

Yes Everything dynamically built is in dist now everything else can be considered "static"

david aka claudekennilol•3w ago

I'm still missing something else ¯\_(ツ)_/¯

Vauxs•3w ago

Did you npm run build it? and is the dist there?

david aka claudekennilol•3w ago

Yeah it's there

Vauxs•3w ago

Then run npm run dev. If you don't see it in Foundry, restart it. If you still don't see it, check the errors.

david aka claudekennilol•3w ago

No errors

Vauxs•3w ago

And of course the module has to be in the module folder :indeed:

david aka claudekennilol•3w ago

Ok that's what I'm missing. I guess I just assumed the proxy took care of that

Vauxs•3w ago

It does not (And it cannot)

david aka claudekennilol•3w ago

Yeah, makes sense. All good now, thanks 👍

Vauxs•3w ago

Right, I should probably PR another thing to the template however Initially made by pf2e system devs and later slightly improved by myself, this lets you do a quick symlink between the module and Foundry

// ./scripts/link.mjs
// ran using npm run link (node scripts/link.mjs)
import { lstatSync, rmSync, symlinkSync, unlinkSync } from "node:fs";
import { resolve } from "node:path";
import process from "node:process";
import prompts from "prompts";
import moduleJSON from "../module.json" with { type: "json" };

const windowsInstructions = process.platform === "win32" ? " Start with a drive letter (\"C:\\\")." : "";
const dataPath = (
    await prompts({
        type: "text",
        name: "value",
        format: v => v.replace(/\W*$/, "").trim(),
        message: `Enter the full path to your Foundry data folder.${windowsInstructions}`,
    })
).value;
if (!dataPath || !/\bData$/.test(dataPath)) {
    console.error(`"${dataPath}" does not look like a Foundry data folder.`);
    process.exit(1);
}
const dataPathStats = lstatSync(dataPath, { throwIfNoEntry: false });
if (!dataPathStats?.isDirectory()) {
    console.error(`No folder found at "${dataPath}"`);
    process.exit(1);
}

const symlinkPath = resolve(dataPath, "modules", moduleJSON.id);
const symlinkStats = lstatSync(symlinkPath, { throwIfNoEntry: false });
if (symlinkStats) {
    const atPath = symlinkStats.isDirectory() ? "folder" : symlinkStats.isSymbolicLink() ? "symlink" : "file";
    const proceed = (
        await prompts({
            type: "confirm",
            name: "value",
            initial: false,
            message: `A "${moduleJSON.id}" ${atPath} already exists in the "modules" subfolder. Replace with new symlink?`,
        })
    ).value;
    if (!proceed) {
        console.log("Aborting.");
        process.exit();
    }
}

try {
    if (symlinkStats?.isDirectory()) {
        rmSync(symlinkPath, { recursive: true, force: true });
    } else if (symlinkStats) {
        unlinkSync(symlinkPath);
    }
    symlinkSync(resolve(process.cwd()), symlinkPath);
} catch (error) {
    if (error instanceof Error) {
        console.error(`An error was encountered trying to create a symlink: ${error.message}`);
        process.exit(1);
    }
}

console.log(`Symlink successfully created at "${symlinkPath}"!`);

// ./scripts/link.mjs
// ran using npm run link (node scripts/link.mjs)
import { lstatSync, rmSync, symlinkSync, unlinkSync } from "node:fs";
import { resolve } from "node:path";
import process from "node:process";
import prompts from "prompts";
import moduleJSON from "../module.json" with { type: "json" };

const windowsInstructions = process.platform === "win32" ? " Start with a drive letter (\"C:\\\")." : "";
const dataPath = (
    await prompts({
        type: "text",
        name: "value",
        format: v => v.replace(/\W*$/, "").trim(),
        message: `Enter the full path to your Foundry data folder.${windowsInstructions}`,
    })
).value;
if (!dataPath || !/\bData$/.test(dataPath)) {
    console.error(`"${dataPath}" does not look like a Foundry data folder.`);
    process.exit(1);
}
const dataPathStats = lstatSync(dataPath, { throwIfNoEntry: false });
if (!dataPathStats?.isDirectory()) {
    console.error(`No folder found at "${dataPath}"`);
    process.exit(1);
}

const symlinkPath = resolve(dataPath, "modules", moduleJSON.id);
const symlinkStats = lstatSync(symlinkPath, { throwIfNoEntry: false });
if (symlinkStats) {
    const atPath = symlinkStats.isDirectory() ? "folder" : symlinkStats.isSymbolicLink() ? "symlink" : "file";
    const proceed = (
        await prompts({
            type: "confirm",
            name: "value",
            initial: false,
            message: `A "${moduleJSON.id}" ${atPath} already exists in the "modules" subfolder. Replace with new symlink?`,
        })
    ).value;
    if (!proceed) {
        console.log("Aborting.");
        process.exit();
    }
}

try {
    if (symlinkStats?.isDirectory()) {
        rmSync(symlinkPath, { recursive: true, force: true });
    } else if (symlinkStats) {
        unlinkSync(symlinkPath);
    }
    symlinkSync(resolve(process.cwd()), symlinkPath);
} catch (error) {
    if (error instanceof Error) {
        console.error(`An error was encountered trying to create a symlink: ${error.message}`);
        process.exit(1);
    }
}

console.log(`Symlink successfully created at "${symlinkPath}"!`);

david aka claudekennilol•3w ago

Seems like a lot of text for a symlink 👀. Well, it seems to be building, the module.json definitely loads up as expected because I can see the mod on the module select page and the module list while in a game. But for whatever reason it's not actually serving up the js. Left is my tree view of the mod vs code showing that the js file is there. Right is the chrome debugger. I've reduced my js entry file to just a lone debugger statement in case there was an error deeper in the mod caused from updating TJS and that doesn't seem to help

david aka claudekennilol•3w ago

Though, I guess since I'm symlinking my repo dir now, I'm not sure what use the dev script is since everything is directly symlinked and I shouldn't need a proxy now Yeah when I just run build instead of dev it works -- so I guess it would be useful if someone could explain to me what I'm misunderstanding about this dev proxy set up Question - should my dist output be named after my mod id or named index.js?

Vauxs•3w ago

after your mod id oh, you dont have an index.js in your src you need to change your input, vite just doesn't see any code here Where does the module begin? the ckl-advanced-templates.pf1.js? @david aka claudekennilol Otherwise you can also just add an index.js directly at src and import it there

david aka claudekennilol•3w ago

Module is configured like this. Previously it was just ckl-advanced-templates-pf1.js but I didn't feel like modifying the build scripts to copy the necessary lang/module/etc files into dist to run directly from there

david aka claudekennilol•3w ago

But essentially, yeah, the "entry point" is that file

Vauxs•3w ago

I am talking about the vite, I think the lib.entry is wrong

Vauxs•3w ago

in comparison

david aka claudekennilol•3w ago

I don't have an index file At least not at the root

Vauxs•3w ago

Yeah, I can see that Change your entry to not be with ./, that's probably the thing breaking it otherwise add an index and change it to just index.js You can see pf2e-graphics config

david aka claudekennilol•3w ago

removing ./ didn't change anything

Vauxs•3w ago

also rewrite this

Vauxs•3w ago

Its a redirect to index.js at root

david aka claudekennilol•3w ago

Got it, thanks 👍

Vauxs•3w ago

I guess worth noting for future @TyphonJS (Michael) Make a const entryPoint or such

TyphonJS (Michael)OP•3w ago

Or some comments explaining that the basic Vite config is configured for the template repo and installing the repo directly in the Foundry modules section. One is free to do whatever makes sense for ones own project setup from entry points to symlinking and beyond.. The Vite config provided works for the demo repos. It's basic, but it also is just a normal Vite config without additional code or complexity.. While we did have a discussion on Discord and I took a look at how you setup things I opted to keep things simple and just retain a normal Vite config that if you look at the Vite docs is understandable. If one doesn't look at the Vite docs and doesn't know how Vite works well that is something to remedy. It's not that your personal preference / custom scripts or how the PF2E folks do things is wrong; it's just opinionated. While what is currently available in the demo repos also is opinionated insofar as opting for direct installation in the /Data folder it errs on the side of simplicity. I also do plan to make a CLI that is more comprehensive and easier to use for standard Foundry package installations; direct /Data installs or symlinking. I wish I had to time to make better template demo repos and content explaining how to get started and where to go if one desires to provide custom modifications.

Gaming

Programming

TRL `0.2.0` Release

Did you find this page helpful?