Migration is looking for a "webpack" subfolder?

[WebMechanic]

Hello and thank you for this project,

I "inherited" some PHP Symfony projects that make use of their Webpack Wrapper Encore. Encore also uses webpack.config.js but adds loads of its own funktions to it.

We move to Vue 3 and I want to ditch Webpack (which I don't care to learn and bother with) in favour of using ESM with Vite and Rollup and their ecosystem.

I managed to get the final Webpack runtime configuration object out of Encore which I then saved as a new webpack.config.js (with mode:development ) in a project copy, after making some path adjustments.

This is the command line for migration:
webpack-to-vite -t webpack -e main.js -d D:\foo\bar

After copying files and starting the "AST Parsing" I saw a partially covered line (by the conversion table results)
Failed to parse webpack config from default file path: D:\foo\bar\webpack\webpack.dev.conf.js.

It took many failed runs to see this line only becuase at one point I resized the terminal window.
I'm surprised to see it looking for webpack/webpack.dev.conf.js despite there is a config file in the project root.
I eventually copied my file to this location and some migration action happened.

However this webpack/ folder also ended up in vite.config.js which let Vite bail with unavailable modules (that are installed):

build: {
  rollupOptions: {
    input: {
      'js/vendor0': path.resolve(__dirname, 'webpack/assets/shared/js/polyfill.js'),
      'js/vendor1': path.resolve(__dirname, 'webpack/assets/shared/js/global-jquery.js'),
      'js/vendor2': path.resolve(__dirname, 'webpack/bootstrap'),
      'js/vendor3': path.resolve(__dirname, 'webpack/bootstrap-datepicker'),
// ...
    },
    output: {
      entryFileNames: '[name].[contenthash:8].js'
    }
  },
  outDir: path.resolve(__dirname, 'webpack/public/Jobs/build')
},

I removed that webpack/ folder prefix and Vite is running.

I get a buttload of other errors unrelated to the migration that I need to review.

[WebMechanic]

follow up:
I'm also wondering why the specially created index.html wasn't added to build.rollupOptions.input.
Vite complained of not having a valid entry point -- the various .js and .css from Webpack were rightfully ignored.

It seems like several configuration setting in Webpack aren't ported to Vite equivalents like sourcemap, emptyOutDir and others (need to dig into it).
I understand that Vite doesn't need as many extras as Webpack and but the config looks "bland" compared to all the settings in webpack.config.js.

[Chieffo2021]

Hi @WebMechanic , thanks for your feedback

I'm surprised to see it looking for webpack/webpack.dev.conf.js despite there is a config file in the project root.

Please make sure your config file is named correctly because our strategy of parsing webpack config file is // first, parse webpack config from path : ${__dirname}/webpack.config.js, only parsing config file from sub-directory when it not in the root directory, reference code:

webpack-to-vite/src/config/parse.ts

Lines 13 to 19 in e052115

	// first, parse webpack config from path : ${__dirname}/webpack.config.js
	if (fs.existsSync(configPath)) {
	try {
	await import(configPath).then((config) => {
	webpackConfig = config
	})
	return webpackConfig

I'm also wondering why the specially created index.html wasn't added to build.rollupOptions.input.

We don't need to do that, because Vite will treat index.html as the default App entry: https://vitejs.dev/guide/#index-html-and-project-root

Vite complained of not having a valid entry point -- the various .js and .css from Webpack were rightfully ignored.

Basically, the webpack entry point will automatic parsing and add to index.html by Webpack-to-Vite, they are present as a js script tag, you can check the entry point in index.html if correct.

webpack-to-vite/src/generate/geneIndexHtml.ts

Line 49 in e052115

htmlWithEntries += ` <script type="module" src="${entryPath}"></script>\n`

I get a buttload of other errors unrelated to the migration that I need to review.

It seems like several configuration setting in Webpack aren't ported to Vite equivalents like sourcemap, emptyOutDir and others (need to dig into it).

Get your point, I appreciate the idea you proposed, and I also want to make it more convenient for users but currently, I don't have much time, so if you like please feel free to open a new PR (for example, list the configuration need to be ported to Vite in README.md) ^_^

[WebMechanic]

Please make sure your config file is named correctly

a webpack.config.js was in the project root where it was used by Encore before to create the build, hence my surprise to see the scripts looking for one in a subfolder.

We don't need to do that, because Vite will treat index.html as the default App entry:

since this is a PHP project, we have no use for .html and that index.html was created by the script but not added to the newly created vite.config.js. Just an observation.

I can't "list the configuration needs" since I don't know what's WebPack let alone what's added by Symfony Encore, which is why I want to use Vite.
I just expected this tool to convert "the usual suspects" such as sourcemap, paths, aliases etc.

I don't have much time either and Symfony Encore requires much more work to migrate away from WebPack to Vite including its PHP backend integrations.
I decided to go with vite-bundle as it also takes care of the PHP part.

Have a nice time.

[Chieffo2021]

I just expected this tool to convert "the usual suspects" such as sourcemap, paths, aliases etc.

I think we are already transferred these configurations sourcemap, paths, aliases automatically. 🤔

I don't have much time either and Symfony Encore requires much more work to migrate away from WebPack to Vite including its PHP backend integrations.

Hope you make it through~ A backend project like PHP does need more work to integrate with Vite, If you can share the project or upload a demo project see if I can help, and also share the experience with other people.

[WebMechanic]

I think we are already transferred these configurations sourcemap, paths, aliases automatically. 🤔

it might well do so :) I only got the js and css entries for the bundles - which was already helpful.
More likely the transforms that Symfony Encore did to the webpack config messed things up and your script didn't find this data. It's a blackbox inside a blockbox...

Hope you make it through~ A backend project like PHP does need more work to integrate with Vite,

Thaknk you.
If it were a PHP Laravel project things would be fin: they already have that integration.
Symfony however haven't (yet) and I don't have time for them to switch their beloved front-end package and its ecosystem to Vite any time soon.

@lhapaipai's vite-bundle pretty much handles the PHP part, but I do loose some webpack configuration details.
A mixture of both packages would be nice :)

If you can share the project or upload a demo project see if I can help, and also share the experience with other people.

Unfortunately I can't. Not with this project.
I may try to setup a vanilla Symfony project, copy this webpack.config.js to it and see if it renders. However, not any time soon.

It'd be interseting to learn how a migration from this "blackbox" could work.

Thanks

[WebMechanic]

Ok, so here's another thought ...
I didn't look at the code nor do I don't know about the inner workings, so maybe this is already happening to some extend in your script ...

Hook into the config as a wrapper (like Encore) and grab what you need, then spit out a vite.[dev|prod].config.js. ¹

Encore virtually replaces every config property with a function call to it's wrapper. It uses a similary named API, just more magic and checks behind the scenes.
It's actually a config object on it own created by Encore that's then "transpiled" into a new config object which is passed to WebPack and eventually exported.
If you just required() the config file, the results within module.exports could be different from what Encore does to the config then passed on to Webpack (see the position of Encore.reset() in the following code sample).

sth. like this:

/** 
 * THE webpack.config.js 
 */

const Encore = require('@symfony/webpack-encore')
const webpack = require('webpack')

/** STEP 1 - LOAD MIGRATION SCRIPT HERE */
const webpackToVite = require('webpack-to-vite')

// ...
Encore
  .setOutputPath('public/Jobs/build/')
  .setPublicPath('/build')
  .configureBabel(...)
  .addEntry('js/vendor',[ .. js files .. ])
  .addEntry('js/app',[ .. more js files .. ])
// many addEntry lines later
  .addStyleEntry('css/vendor',[ .. scss files ... ])
  .addStyleEntry('css/app',[ .. more css and scss files ... ])

// many addStyleEntry lines later
  .cleanupOutputBeforeBuild()
  .enableSassLoader( ... some options ... )
  .enableSourceMaps( !Encore.isProduction() )
  .enableBuildNotifications()
  .enableVueLoader(() => {}, {  // this is a Vue2 Project
    useJsx: true,
    runtimeCompilerBuild: false
  })
  .enableVersioning()

  .addAliases( object with aliases )
  .copyFiles( .. )
; // end-of

/* further "processing" */

if ( Encore.isProduction() ) {
  Encore..enablePostCssLoader()
}

/** FINALLY a configuration object */
let wpConfig = Encore.getWebpackConfig()

/** STEP 2 - HERE IS WHERE THE MAGIC HAPPENS */
webpackToVite(wpConfig)
    .writeConfig('vite.migrate.config.js')

// I don't know why this is/must be down here ... maybe Encore can't handle 3rd party plugins
wpConfig.plugins.push(
  new webpack.DefinePlugin({  some ENVs replacements })
)

/**
 * Resets the Encore state to allow building a new config.
 * getWebpackConfig should be used before resetting to build a config for the existing state.
 * @returns {void}
 */
Encore.reset();

module.exports = [wpConfig];

I can't just "dump" this wpConfig object into a JSON as the result would be static and already contain any transforms and trickery done by the various plugins.

When called as yarn encore dev or yarn encore production this may also detect the runtime environment and create separate vite.dev.config.js and vite.production.config.js so one could see the different outcomes of WebPack (Encore) dev vs production like loading the PostCSS or Terser plugins in the production build only.

I'd be totally fine to temporarily add that "wrapper call" into the existing webpack.confg.js, let it do it's magic and once I have my vite configurations (plural) rollback the edit.

One might then "merge" the findings and settings of both files into/with an actual/existing vite.config.js using their methods to switch dev and production settings as need be.

Have a good time.

---

Footnotes

1. I installed Vite and Vitest side-by-side into an Encore project. If it's only used for unit testing, no bundling.
   Neither Encore nor WebPack will care, but if the migration script writes it own new vite.config.js it'd potentially overwrite mine. Passing the target filename for Vite's configuration would be safer. It' no run-and-done anyway as one needs to make some adjustments. ↩