vite.config.ts doesn't work

[Olivki]

There's two issues with the reading of the vite.config.ts file.

• On Windows (haven't tested on other systems) the file can't be imported with the error: Only URLs with a scheme in: file, data are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Changing (await import(userDefinedConfigFile)) to (await import(`file://${userDefinedConfigFile}`)) fixes it, but this probably only works on Windows, so a platform check might be required?
• The module importer can't handle TS files, and as such the vite.config.ts should instead be vite.config.js

On a side note, the newly added Babel transpiler doesn't seem to actually work, but a vite.config.js file looking like this:

import { getBabelOutputPlugin } from '@rollup/plugin-babel';

export default {
  build: {
    rollupOptions: {
      plugins: [
        getBabelOutputPlugin({
          allowAllFormats: true,
          presets: [
            [
              '@babel/preset-env',
              {
                useBuiltIns: false,
                exclude: ['transform-typeof-symbol'],
                modules: false,
                targets: {
                  ie: "11"
                }
              },
            ],
          ],
        }),
      ],
    },
  },
};

Based on this comment gets the Babel transpilation to actually work. The Babel output probably needs additional tweaking to be perfect for KubeJS, I only did some quick testing with it.

[MDReal32]

Working on it.

[Olivki]

After some further looking around, it seems Babel does support Rhino as a target for transpiling, so that might be worth looking into.

I can't get nullish coalescing operator transforming to work no matter what I try however, while all the other ES2020 features seem to transpile like they should, like null chaining. Hopefully you'll have more success.

[Olivki]

The Babel output works now as of version 1.1.5, but in my attempt to customize the output of Babel (because Rhino seems to have issues with how Babel handles transforming for of loops) I stumbled upon more issues that I didn't notice before.

From my testing, regardless of the value in vite.config.js, be it export default defineConfig({}), export default defineConfig({..} => ..) etc, the type of userDefinedConfig will always be object, and never function. This seems to be because even though we're defining a default export, we get back the actual module object, so to actually do what was intended here, we'd need to do something like this:

const userDefinedConfig = (await import(userDefinedConfigFile)) as UserConfigExport;
const configValue = userDefinedConfig.default;

if (typeof configValue === 'function') {
	const result = await userDefinedConfig({
		command: "build",
        isPreview: false,
        isSsrBuild: false,
        mode: "production"
	});
   Object.assign(baseConfig, result);
}

In my testing, something like this will allow the config to actually be properly retrieved.

And now onto the second issue: I'm not sure what the actual intent was with using Object.assign, because it will completely overwrite baseConfig with result if it has any nested keys, which, it most likely will, as we'd most likely be configuring the build step. We aren't passing along the already constructed config object either.

The vite.config.js file seems to be intended to be used for all three targets, client, server, and startup, meaning there's no realistic way for a user to actually properly construct a single config object that's valid for all three targets, especially not when no data about which target it is (at least not from what I can see, I apologize if I missed something, I'm not a JS dev), is passed along to the user.

Seeing as the project already uses lodash, the simplest solution seems to be to replace Object.assign(baseConfig, result) with _.merge(baseConfig, result) which properly merges the two configs. Passing along the data needed to construct valid config objects to the user could also potentially work, but being able to just define partial configs seems a bit more convenient.

I could probably open a PR for this if desired, I can't guarantee code quality however, as I've barely touched JS/TS before.