Age calc with moment in task.js

[jkuester]

@Anro

While the luxon impl works in dev, will it work in a production build?

Not 100% sure, but I think that since Webpack is going to do its thing from the dev environment, it technically might not matter that it is a transitive dev dependency. The necessary luxon code will be wrapped up with your task code when it gets uploaded to the server. (Once again, this is just how things work in my head, I have not confirmed this to be true.) All that being said, if you are going to depend on luxon in your implementation code, then semantically you really should add luxon to your list of dependencies in your package.json. You do not really want to simply depend on whatever version the test harness happens to use.

@Anro

Where do tasks run/how does it work?

So, as I understand it, Sentinel does not have anything to do with generating/scheduling “tasks” (aka the user tasks configured in the tasks.json). For these tasks to work offline (and be responsive to data that only exists on the client and has not been synced to the server), they have to function completely within the client-side webapp. To dig in more to the code flow of tasks, the rules-engine.service getTaskDocsFor function is probably a decent place to start. The client uses the rules engine to interpret the provided tasks.js config and generate tasks based on the client’s current data. If you really want to get into the guts, here is where the code from tasks.js is loaded. Then, that function is called here when getting/initing the tasks data for a user/contact.

@Anro

This is where we then use the luxon lib in order to calculate if the person is less than 5 years old, and display the task for them.
The webapp itself only has the moment dependency, does this mean we’re depending on a library of a library?

I think the piece you are missing here is that webapp does not actually need to depend directly on luxon just to run your task code. As I mentioned above, webpack will cram all your code and its dependencies together before uploading it as part of your app_settings. Then, when the webapp actually goes to run your task code, it does not know or care about luxon, but your packaged app_settings have all the code needed for your logic to work (regardless of what webapp depends on).

This was part of the trickiness that Kenn was getting at earlier. Your webpacked task code (prior to 4.2) would get automatically parsed by nools. The reason this limited the dependencies that could be used in the task code was because nools would also parse the packed dependency code as well (since webpack would bundle it all up together).