Support for 'built' web resources

[filcole]

It would be great if the the Power Platform CLI could be enhanced for 'built' webresources, e.g. transpiled TypeScript, minified JavaScript, reduced image resources, resx files, etc. Perhaps something similar to pac solution add-resource-reference, along with a new project type pac resource init --kind TypeScript to initialise a TypeScript webresource project.

In my test repo (https://github.com/filcole/pacbuild) I've experimented with building a PCF, plugin, solution and package deployer package using just the pac tooling, which works great. A large remaining gap is webresources, since there is often there is a need to transpile webresources and include them in a solution using a mapping xml file.

Additionally often there is a need to use multiple npm packages, especially with TypeScript builds, e.g. prettier, ESLint, webpack/rollup/parcel, @microsoft/eslint-plugin-power-apps, @types/xrm, etc. Perhaps even sometimes running unit tests with Jest. It would be good if any setup could also include recommendations/guidance on restoring npm packages (npm install or npm ci) as part of a build.

One concern with the pac solution add-reference style, is how one might incrementally build a package. Currently in a hosted github/devops pipeline the MSBuild style will build everything on every build without the ability to use pipeline caching or pipeline artefacts to reduce the build duration. Is this a limitation of MSBuild, or are there techniques to use here?

I think this may be a common issue, since there are many blogs/forums/tweets asking how one might do this:
https://twitter.com/EffEyeEll/status/1567929125310009347
https://learn.develop1.net/courses/building-javascript-web-resources-using-typescript
https://benediktbergmann.eu/2020/12/04/setting-up-a-typescript-project-for-dataverse/
https://xrm.al/blog/typescript-dataverse
https://www.youtube.com/watch?v=VsKsfNkzL50
https://dev.to/oliverflint/d365-typescript-web-resources-part-1-basics-10lg
https://www.xrm.dev/typescript-xrmdefinitelytyped/
https://www.youtube.com/watch?v=THxc7qTaUD8
https://nilsgoldenstein.com/how-to-typescript-in-dynamics-365-0-of-6

[daryllabar]

I think one of the biggest hurdles this faces, is the ever changing JS/TS world. How quickly would the setup project fall out of date? Second issue would be how do you pick the default settings/libraries. There are just Soo many options.

[BenediktBergmann]

+1 for what Daryl wrote. It was the first thing that came to my mind as well.
There are so many options that I have never seen 2 projects doing the same thing (besides the projects I have set up with a template ;) ).

On the other hand, it could be good for someone who is new in this space to get some guidance. But it would have to be dynamic enough to handle different setups. So that a more experienced (and maybe opinionated) person could change it to their needs.

[magesoe]

Love the idea!
One way of getting around the ever changing js world is to provide a run, build, test and so on definition in the package json, but allow us to change it. Then you know the pac cli will call npx run build and we can add whatever we want to it if we adapt the setup

[BenediktBergmann]

Basically, an interface/contract which we could extend or alter if needed. I think this is a great idea and a perfect way of using what the platform already has

[OliverFlint]

I'm on the fence a little with this one. I'd actually be happy to use the external build tools for TS/JS, plugins, and other code components and then map them into a solution. This retains all the "native" build tool flexibility. Wrapping those build tools into the packaging process will invariably create restrictions in the future. (I've been to the pub so may be talking rubbish)

[rexkenley]

MS could just extend webpack that they are currently using for pcf.

Webpack 5 is fairly advance and easy to use with their new 0 configuration feature. If one needs a custom config, the same pcf webpack custom config scheme works well.

https://webpack.js.org/configuration/

For work I have created an dev build system that incorporates all the best practices tooling for large dev teams. It is almost similar to filcole's feature set. A coder can just install the npm package and select the desired function from a gui menu. The goal was to allow a js coder hit the ground running by "abstracting away" the non-js part of d365 development as gui menu option.

[davidjenni]

@filcole @daryllabar @BenediktBergmann @magesoe @OliverFlint @rexkenley yes, interest webresources support has seen a recent renaissance. We've had internal discussions on what support we could and should add for JS/TS web resources, but nothing is decided yet.

I'm moving this into the discussions area until we have a more concrete plan to communicate.

@kkanakas

[dmcweeney]

Agreed with all the sentiments mentioned above....

See this issue for more variables to throw into the equation - Issue #349 (Enhancement - add pac webresource push).

IMO there is a massive gap not being able to push a built webresource to a solution via cli.

[dmcweeney]

@davidjenni - Any updates on these plans?

[jbuenoliveira]

Would be awesome to have a pac command to init and push webresources. Any update?

[dmcweeney]

Recommendation in the docs now is to provide feedback in the build tools repo.
For reference I have added this there - microsoft/powerplatform-build-tools#770.