[QUESTION] Integration with Vite

[go4cas]

Hi @stephancasas. So, my boilerplate with the component based structure is coming on nicely. I have, however, decided to swap out rollup with Vite, for build and bundling. Everything works really well. I just want some advice on one item, when including presto in my build chain.

Vite relies on the index.html file as its starting point. So, before adding presto to my app, the build would basically do the following:

• Scan index.html from the src folder
• Change relative paths for assets, etc in this file
• Work through index.js in the src folder, which is embed in the index.html file, and does all the js imports, bundling, etc, etc
• Then copy over the final bundle (including the changed index.html) to the list folder

All of this works 100%.

Now, when including presto in my project, I will have a situation whereby both presto and vite need to make changes to the index.html. The only way I can see around this is:

• Create a new "main" html file in src (example app.html)
• Then change my presto.config.js to look something like this:

export default {
  input: 'src/app.html',
  output: {
    file: 'src/index.html',
    formatting: 'none'
  }
}

• My build commands will then be:

"build:markup": "presto --config presto.config.js",
"build:bundle": "vite build",
"build": "npm-run-all build:markup build:bundle"

• The theory is that presto will do its magic, and then create the index.html that vite will use to build and bundle

Does this make sense? Can you think of an easier/better way to achieve this?

[go4cas]

I have now tested my approach, and the two step build works as expected. I am just not sure if the dev server will work in the same way.

[go4cas]

I think I have finally figured this out.

• I have changed all my presto markup files, from index.html to index.pres - this is to ensure that nodemon listens for changes to these files, and then kick off presto, and that they will be ignored by Vite's dev and build processes.
• My main app markup file is called index.press
• presto.config.js looks like this:

export default {
  input: 'src/index.pres',
  
  include: [
    'src/components/**/*.html'
  ],
  
  output: {
    file: 'src/index.html',
    formatting: 'none'
  }
}

• These are my npm scripts:

    "watch": "nodemon --watch ./src -e pres --exec \"npx presto && vite\"",
    "serve": "vite preview",
    "build:markup": "presto --config presto.config.js",
    "build:bundle": "vite build",
    "build": "npm-run-all build:markup build:bundle"

• Now, whenever I make changes to my .pres files, Nodemon will execute presto, rebuild my index.html, which will trigger hot reload by Vite

What do you think about this?

[go4cas]

What would be ideal, is to have a rollup/vite plugin. Then presto could become part of the normal build/serve chain.

[stephancasas]

I've had a chance to clone and test your scaffolding and think this is a good approach given the current options made available by Presto. Mentioned in the documentation, I'd like to get chokidar bundled-in with Presto so that developers will have more options available to them like an npx presto --watch ... command, but until then nodemon is doing the trick nicely.

As far as order of execution goes, I think you've hit it exactly. The only additional consideration I might add would be in adopting .pres.html as part of your extension nomenclature for no other reason than it will save developers the time of having to tell their editor/IDE to apply HTML syntax highlighting to .pres files. As I've also recently learned that everyone's favorite code formatter, Prettier, throws a fit if extensions don't exactly match what it's expecting to see or equivalence isn't specified in the IDE's preferences, this can potentially save some trouble down the line as well.

A plugin would be a terrific approach to handling this. Additional issues have been brought to my attention which are pushing me further and further away from cheerio as the DOM processor in Presto. Once I've landed on a nice replacement, I intend to swap it into the current codebase, clean-up the structure, and then stage for an open release. In this way, it'll be nice to get some additional eyes on where plugins can hook into Presto — generating what I think will be really valuable insight, especially for frameworks/utilities like Vite.

Keep up the solid work! I'm looking forward to trying-out W.A.S.P this coming week!