Jump to content

any Prepros gurus in here who can help me understand JS Bundling ?


Recommended Posts

Hello PW forums,

I started using Prepros after coming across it on various discussions here. I've got a local dev environment going using Prepros + MAMP server as proxy. I was curious to try this specifically for the bundling js feature. I am trying a new folder structure and wanted to experiment with some Node.js package (via npm). My project is structured:

├── node_modules
├── src/
│   └── js/
│       └── main.js
├── wwwroot/
│   ├── site/
│   │   └── templates/
│   │       └── scripts/
│   │           └── main-dist.js
│   ├── wire/
│   └── index.php
├── .env
├── package.json
└── prepros.config

ProcessWire core lives in the wwwroot and is served via MAMP configured as a virtual host to that specific path and served at https://localhost:8848 via. Prepros.

Because I am not spinning up npm run dev or node locally, I bundle the main.js via Prepros JS Bundle features to get a main-dist.js file that I move into the PW site/templates/scripts/ directory and which I then call in the _main.php <head> section in /site/templates/


I also specify the Global Variables in Prepros (.env variables that I want to access in main.js)

const chains = [mainnet, polygon]   
const projectId = process.env.WALLET_CONNECT_PROJECT_ID;
const alchemyKey = process.env.ALCHEMY_API_KEY;


Now interestingly when Bundling JS with Prepros, it creates several named files in addition to the main-dist.js file, which I need to also include into the site/templates/scripts/ dir otherwise it I receive errors in console. I don't understand what exactly all those files are really doing other than … dependencies being bundled ?



Finally, the Global variables I set in Prepros do not seem to be defined when reloading the local dev/server (console errors). Is there something I am missing? This .env variable business has really taken me for a spin … especially seeing as how in production the parameters change quite substantially. I am not sure what the best practice is for production, but I seem to be trying to adhere to standard practice for local dev ?

Any pointers from Prepros users much appreciated!

  • Like 1
Link to comment
Share on other sites

@protro nice tool, I think I am going to build something similar but based with vite/rollup.

About your issue, as you pointed it, your are serving your website from MAMP server, then the env will not be available on built app when served by MAMP and you will need to use a solution like php dotenv, and I saw you already read the thread about dotenv then I assume you got it working ?

It's also worth noting that by using prepros you are bundling your app with webpack and not vite or rollup, keep in mind that when you will head to js libs documentation or when trying to find what's is not working.

Under the hood, there is the stack list:

Webpack 5.86.0
Babel 7.22.5
Autoprefixer 10.4.14
Node Sass 9.0.0
PostCSS 8.4.24
PostCSS Preset 8.4.2
Dart Sass 1.63.3
Tailwindcss 3.3.2
Terser 5.17.7


On 8/10/2023 at 10:11 PM, protro said:

dependencies being bundled ?

Yes. Or to be more precise, what we can call Entry points. It contain the entry point of your app and the vendors. For more information about the splitting process head to webpack doc.

  • Like 1
Link to comment
Share on other sites

thanks @flydev this helps. I haven't got php dotenv to work yet. I realize my API secrets were getting bundled into PrePros's JS dist bundle. I've been looking for solutions, even thought that maybe I could store it in a PW page's field, but I have hit a block when thinking of ways I'd be able to access that from within my javascript src code.

Looks like with Vercel, Netlify, et al the ENV variables can be stored in their dashboard. Otherwise it looks like a proxy server for API keys on the backend is the way to go, but a little complicated for my situation.

  • Like 1
Link to comment
Share on other sites

Yes, and I misread your post, I didn’t paid attention that the site is served from MAMP through prepos proxy.

And as you already spot, they are transformed in your bundle source. Keep in mind that all process calls are Node.js things and aren’t available in the browser. 

Anyway, on the example of Alchemy, the api key is made for you, what I mean is, the front app make a request to ProcessWire endpoint, then the needed requests are made from ProcessWire to alchemy endpoint using your api key stored on server side, eg. in template or module, db, .env file/process, then Alchemy answer your server, and finally, ProcessWire send back the response to the front app.

It seem you got the idea. What is complicated on your side, if I can help?

If is just to test and see external services like alchemy from local, just do not scratch your head to much, and use them as they are, included in the bundle. Using env variable on this case make things easier than going into the source code to change them.


  • Thanks 1
Link to comment
Share on other sites


needed requests are made from ProcessWire to alchemy endpoint using your api key stored on server side, eg. in template or module, db, .env file/process, then Alchemy answer your server, and finally, ProcessWire send back the response to the front app.

this is outside of my usual expertise @flydev … conceptually it makes sense but I have been not the best problem-solver when it comes to determining how to handle these responses from backend -> front end. I'd like to follow best practice from security standpoint, of course … and I feel like I'm getting very much "in the weeds" meaning I may be over-complicating things, as you stated.

Locally everything works fine with the env variables in my PrePros/MAMP proxy setup. It's on the production site where I am running into questions and complications, as I am trying to be as careful as possible to not leak any keys.

Link to comment
Share on other sites


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...