Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extremely slow starts if kirbyup.config exists #19

Closed
jonaskuske opened this issue Aug 9, 2022 · 3 comments · Fixed by #21
Closed

Extremely slow starts if kirbyup.config exists #19

jonaskuske opened this issue Aug 9, 2022 · 3 comments · Fixed by #21

Comments

@jonaskuske
Copy link
Collaborator

When there's a kirbyup.config.(js|mjs|...) in a project, kirbyup takes roughly 20x as long to start building (or with #18: serving) the plugin.

Without a kirbyup config, my plugin build finishes in ~0.7s. If a kirbyup config exists, it takes ~14s, almost all of which is the loading of the config. I added a console.log to my config file – nothing happens for ages, then the config executes and is logged and shortly after the build completes.

I guess unconfig takes long to check all possible config paths and then compile the found config? But no matter the cause, not a great experience :(

@johannschopplich
Copy link
Owner

johannschopplich commented Aug 9, 2022

Yeah, I've noticed that one too when tests were still using an execution strategy with npx tsx cli.ts. I have no idea why it takes that long, tho. Especially, since UnoCSS for example loads configs with unconfig much faster. Maybe a misconfiguration on kirbyup's side?

I adapted a lot of code directly from the UnoCSS loading strategy.

Side note: Actually I don't know of a single project that uses the features of a custom kirbyup config. Just for the assessment of the relevance, scope and urgency of the ticket.

@johannschopplich
Copy link
Owner

johannschopplich commented Aug 9, 2022

Can you confirm loading a kirbyup.config.js is much faster with:

export default {
  // ...
}

instead of:

import { defineConfig } from 'kirbyup'

export default defineConfig({
  // ...
})

…?

Because if so, for a temporary workaround I might just update the README to use export default {} instead.

@jonaskuske
Copy link
Collaborator Author

Confirmed!

And makes sense, Node has to load and run all of these imports just to get the defineConfig:

import 'node:fs';
import 'node:fs/promises';
import 'pathe';
import 'vite';
export { b as build, d as defineConfig, s as serve } from './chunks/index.mjs';
import 'postcss-load-config';
import 'postcss-logical';
import 'postcss-dir-pseudo-class';
import 'consola';
import 'perfect-debounce';
import 'picocolors';
import 'vite-plugin-full-reload';
import 'fs';
import 'path';
import 'module';
import 'crypto';
import 'zlib';
import 'util';
import 'unconfig';
import 'magic-string';
import 'detect-package-manager';

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants