Thanks for this great tool @johannschopplich!

Currently running into an error when trying to start kirbyup with the new HMR feature.

Starting kirbyup from within a plugin with kirbyup serve src/index.js will result in this error message. There is no custom config applied. This is on macOS 12.3.1 and using node v18.6.0.

kirbyup v2.0.0                                                                                                                                                                                                                                                                                11:40:37
ℹ Starting development server...                                                                                                                                                                                                                                                              11:40:37
node:internal/errors:477
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_INVALID_URL]: Invalid URL
    at new NodeError (node:internal/errors:387:5)
    at URL.onParseError (node:internal/url:564:9)
    at new URL (node:internal/url:644:5)
    at new URL (node:internal/url:641:22)
    at Server.<anonymous> (file:///project_path/node_modules/kirbyup/dist/shared/kirbyup.1b72ea0c.mjs:3429:26)
    at Object.onceWrapper (node:events:627:28)
    at Server.emit (node:events:525:35)
    at emitListeningNT (node:net:1465:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:81:21) {
  input: 'http://::1:5177/',
  code: 'ERR_INVALID_URL'
}

Node.js v18.6.0

Currently kirbyup only allows building the plugin, either for production or using the --watch option, with full rebuilds on change.

Not sure if it's feasible, but a dev server mode with HMR would be great, especially for Vue components!

Hey there,
when using kirbyup (which is great), I get this: error [email protected]: The engine "node" is incompatible with this module. Expected version "^16 || ^18". Got "19.4.0" - the README however states Node v16 or newer, so .. took me by surprise 😅

Cheers
CHE1RON

I guess I need to tweak the kirbyup config file to get it to work with DDEV, but I have no idea how.

I currently assume there is no reason to stay below v1.0.0. At least I don't see anything unstable with Kirby Up and therefore would recommend, or better ask, to bump the version to v1.0.0 unless there are any immediate breaking changes in the pipeline.

Staying below v1.0.0 for usage in production has a bit of a drawback: Tools that use semantic versioning to e.g., notify about updates, automatic patching and so on, rely on correct semantic versioning to be used with all their features.

Like, I use Renovate (similar tools: Dependabot) for dependency updates. Usually, minor releases in the pre 1.0.0 release are considered possible breaking changes too. Therefore, Renovate will not automatically patch my websites.

The situation gets much clearer with a v1.0.0 upwards release.

Vite uses --mode production to set mode. kirbyup --mode silently fails for me.

I am also not sure how to get to the mode from kirbyup.config.js because import.meta.env is undefined.

I really just needed sourcemaps for development so i did it the old lame way

export default defineConfig({
  extendViteConfig: {
    build: {
      sourcemap: process.env.NODE_ENV == 'development' ? 'inline' : false
    }
  }
})

and using "NODE_ENV=development kirbyup src/panel/index.js --watch"

The newly introduced plugin for component-cleanup removes the __file property from components in both production and development builds. This property is used by the HMR runtime as component ID, which is why HMR is broken at the moment.

The reason for the new plugin is that since Vite v4, even production builds contain the debug __file property, which should definitely not be published. This is ultimately caused by kirbyup not using Vite's plugin and config system but building its own on top, therefore not giving Vite the chance to handle mode / NODE_ENV settings:

kirbyup starts (NODE_ENV is undefined)
↓
loads Vite config and plugins
↓
postcss-load-config sees that NODE_ENV is undefined and sets it to development
↓
kirbyup calls vite.build()
↓
vite sees that NODE_ENV is already set and does not change it to production
↓
the component compiler emits __file props since NODE_ENV is development

If kirbyup were a Vite plugin, Vite would load first while NODE_ENV was still undefined, set it to production and then kirbyup would load. So during the whole process NODE_ENV would be production and postcss-load-config would have no reason to mess with the value.

It worked in previous versions as Vite forced NODE_ENV to production during build in v3, no matter if it was already set or not. So NODE_ENV was undefined for the first and development for the second half of kirbyup's config and setup phase but then set to production during the actual build, where the compiler checked whether to emit __file. Always was iffy and inconsistent, but fortunately did not cause problems.

The feasible fix (other than turning kirbyup into a Vite plugin and thus giving Vite control over both init/config and build processes) is to set NODE_ENV manually to the correct value as kirbyup starts.

Hi, thank you for this package!
Since a few days and on several machines I run into the following error:

1. When I run npm run dev, I get the following error:

npm ERR! Error while executing:
npm ERR! /usr/local/bin/git ls-remote -h -t ssh://[email protected]/src/index.js.git
npm ERR! ERROR: Repository not found.
npm ERR! exited with error code: 128

{
  "scripts": {
    "dev": "npx -y kirbyup src/index.js --watch",
    "build": "npx -y kirbyup src/index.js"
  }
}

2. When I run npx kirbyup src/index.js --watch directly everything works as expected
3. When I run npx -y kirbyup src/index.js --watch I get the same error as above. So maybe it is the -y flag that is causing the error?

The error description looks like if the code tries to assess the ssh://[email protected]/src/index.js.git repo, which looks incorrect...

Hello.
I'm running in a weird naming convention issue on kirbyup v2.1.3 and Kirby 3.9.0
I have a regular component named PercentageFieldPreview.vue which throws a syntax error when I'm importing it in my src/index.js file.

import PercentageFieldPreview from "./components/PercentageFieldPreview.vue";

Renaming the component file (and import) to PercentagePreview.vue (or anything not *FieldPreview.vue) fixes the issue.

So now I'm wondering if there might be some kind of naming convention for KirbyUp ?
Maybe this has todo with auto import features ? (which I'm not using).

Note: My kirbyup configuration is a bit weird as I'm on osx 10.12 which isn't supported anymore by esbuild so I'm using esbuild-wasm with an npm override, but I don't think it's related.

// in Package.json
"overrides": {
  "esbuild": "npm:esbuild-wasm@latest"
},

Not sure how to debug this but just existence of kirbyup.config.js (or .ts) silently kills the process.

Happens on v0.22.2, v0.22.1 (on this version there is error which i assume from commit history is unrelated), v0.22.0

Both on [email protected] and [email protected]

When i create vite.config.js error is thrown. I assume thats reason for kirbyup.config.js to exist so you can provision some defaults.

Honestly i just wanted to add sourcemaps to js build (maybe good idea to add to development mode defaults) so i can see correct line numbers with errors/logs in console.

Hi,
I am a total newbie to Vue and I’m trying to implement a pagination component inside a kirby panel vue but without success (datas comes from an array) .

I'm stuck with the loading of external components like this one: HENNGE/vue3-pagination (github.com) or other(s) that would live inside index.js (I think...).

I don't know where to start: kirbyup.config.js? Please, would you mind to point me in the right direction?

Thank in advance for your help.

Originally reported by @crisgraphics in getkirby/kirby#4907.

When saving a Vue component while running npm run serve, the following error is thrown in the Panel:

usedComponentDefs[componentName] is undefined

The error will occur with the panel starter kit. @jonaskuske would you mind, taking a look? It's probably related to getkirby/kirby#4820 and https://github.com/getkirby/kirby/pull/4884/files. Thank you. 🙂

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 :(

Hello, I have a issue that looks similar to #8 but which also happens during the dev process and with another library.

One year ago I have made a panel field plugin which uses some of the components provided by vue-grid-layout. At that time I did the plugin compilation with Parcel 1 and it worked, but now Parcel 1 seems to be obsolete and I cannot make it work with Parcel 2.

So I thought I could use Kirbyup to do it as it seems to be simpler, but I am struggling to make it work either.

There is a Vue is not defined error which is thrown in the browser console during dev or after a build process.

Like for Sylvain, the error is related to the following line from the compiled js file :
(...) window.panel.plugin("samrm/dda-mosaic",{fields:{mosaic:_n},blocks:{mosaic:ri}})})(Vue);

It seems Vue is imported somewhere inside vue-grid-layout which breaks the process, but I don't think any call to Vue.extend is in use here.

Any idea on how to handle this issue? Does it make sense to try to adapt the patch you provided to Sylvain (which seems to be designed specially for the build process)?

Thanks!

Errors that are not PrettyErrors are silently discarded:

I ran into problems because I had no postcss.config.js in my plugin folder. This caused kirbyup to look for the file higher up in the tree, where it found an incompatible version of it.

I had to add else { console.log(error) } to find out what went wrong.

Hello! I'm in the process of updating all my plugins' build processes for kirbyup, it's been a pleasure so far, thank you! 👏

The only one that's not playing nicely with it for now is my code editor plugin. It requires:

• prismjs (link)
• vue-prism-editor (link)

The previous build process used parcel, it worked fine but it added vue itself to the bundle, which was a pity but the only way I got it to work.

I made the change for kirbyup (see this branch), which is much more lightweight 👌 but also doesn't work at the moment. It seems to assume it can rely on a global Vue:

(...) panel.plugin("sylvainjule/code-editor",{fields:{"code-editor":_e}})})(Vue);})(); [end of file]

Which triggers the error upon loading in the panel:

Vue is not defined

I don't think the build process is at fault here, but can you confirm my issue would rather be with Kirby / how Vue is exposed than kirbyup?

Thanks!

I'm not sure this necessarily belongs here, but I've just spent an hour debugging it, and I thought it should be noted somewhere, and since kirbyup + tailwind is one of the official examples, I thought you might want to include a warning or a note:

If you're using kirbyup with tailwind in two separate plugins, and the latter uses the same class as the one loaded earlier, it might happen that your responsive tailwind classes will stop working, since kirby just smushes the generated CSS together into one CSS file.

Example:

/* first-plugin/index.css */
.p-2 {}
.lg\:p-4 {}

/* second-plugin/index.css */
.p-2 {}

Now the element with p-2 lg:p4 from first plugin will stay at p-2, since the second plugin redefines the p-2 class much later in the resulting index.css file.

Solutions:

• either configure the first plugin to use important by default, which is stupid
• prefix the latter (second) plugin with a custom tailwind prefix, so the css classes don't colide

I'm getting an error like this:

[vite:css] Cannot read properties of undefined (reading 'config')
file: /path/to/project/site/plugins/packer/src/components/Packer.vue?vue&type=style&index=0&lang.css

 ERROR  Build failed  

When running from the default Kirby plugin creator kit (kirbyup src/index.js --watch, and kirbyup src/index.js).

This starts happening once I add a <style> tag to a Vue SFC that I import into src/index,js.
I did not add any custom configuration and it's a pretty much standard plugin setup:

Node version: v16.13.2
Kirbyup version: kirbyup/0.23.0

Don't know if this matters; the plugin is inside a site/plugins folder of a kirby site that has postcss.config.js tailwind.config.js files in the root directory. The plugin however does not use or rely on them. (Simply there are such files in a parent directory).

How can I help debug this better?

Hey,

thanks for the great tool! I'm using it for the first time and I ran into a problem. I found a solution for it and want to document it for others and my future self.

In my setup, the hot module reloading breaks:

The reason is that my development server is serving the website via https and the browser tries to create the socket connect via secured websocket (wss). Turns out forcing a unsecured connection (ws) via vite config fixes it:

// kirbyup.config.js
import { defineConfig } from 'kirbyup/config'

export default defineConfig({
  extendViteConfig: {
    server: {
      hmr: {
        protocol: "ws"
      }
    }
  }
})

Currently all assets imported in the frontend portion are included in the JS/CSS files as data URLs. This means that importing a single image can blow up the size of the JS to be parsed and executed to multiple MBs!

Would be great to somehow skip inlining the assets, but it doesn't appear that easy to solve, as the problematic behavior is built into Vite and not configurable:

• https://vitejs.dev/config/build-options.html#build-assetsinlinelimit
• vitejs/vite#4454
• vitejs/vite#3295
• vitejs/vite#5028

Optimal would be some integrations so assets are loaded from the plugin's assets/ folder which Kirby automagically copies to the /media directory: https://getkirby.com/docs/guide/plugins/plugin-basics#plugin-assets

Hello,
Using kirbyup for a plugin I make, I tried to import files from kirby/panel, which doesn't seem to be supported.
My use case is to import some props and extend some Kirby Vue components (a fields-section with tabs added to it).

Some of them work using relative paths (../) but not those that depend on other kirby mixins (and ../ is installation-specific too) :
import FieldsSection from "~/../../../../kirby/panel/src/components/Sections/FieldsSection.vue";
Which fails at importing @/mixins/section/section.js. (view source: FieldsSection.vue)

Kirby seems to use the @ sign to resolve kirby/panel/src/, which doesn't seem to conflict with kirbyup's ~ path-resolver.

Do you think something like that could be added to kirbyup ?
One could then do : import FieldsSection from "@/panel/src/components/Sections/FieldsSection.vue";
It would give extensions access to more custom enhancements on almost any part of the panel.

Which brings me to a related question : Are we allowed to extend Kirby's core panel components ? (ping: @bastianallgeier)
If not, then something like allowing to extend sections like fields could solve my particular use case, but that's out of this repo's scope.

Right now the import function has this signature:

import(modules: Record<string, Module>): Record<string, any>;

But the example suggest that using a blob-string instead of a modules record is possible. Which will result in typescript errors, or am I missing something (I guess the blob-string gets transformed into a record by vite)?

kirbyup.import('./components/blocks/*.vue')

Gday.
This: kirbyup './site/plugins/myplugin/src/index.js' --watch outputs the index.js to the root.
...istead of ./site/plugins/myplugin/src/

Hi Johann.
Unfortunately, --out-dir does not do what it is supposed to. kirbyup will not run with this setting. 🤷‍♂️
Here's is a example of my command:

kirbyup site/plugins/blocks/src/index.js --out-dir site/plugins/blocks/ --watch

Would be great to directly see how big the JS and CSS files are

What's your workflow for debugging in the browser? I installed vue dev but it didn't recognize the components...

In Kirby's vite.config.js, we use the postcss-logical and postcss-dir-pseudo-class plugins to transform CSS syntax related to RTL language support. I think it makes sense if Kirby plugins would also be able to use the same syntax for full compatibility with RTL localizations of the Panel.

Hi, i think i found a bug in watchmode. If an error occurs the watch/dev-mode will crash. I think it's better if the process continues and waits for the next change.

Hey there,
i started using kirbyup to write a panel plugin. The building process works well for the index.js, but like described in the cookbook recipe from kirby, kirbyup should compile my sass into the index.css, which is not working.

I created an index.scss file inside plugin-diretory/src, the npm-watcher detects a change inside the file, but no index.css is generated.

Can you tell me what need to be done here?

This is my package.json:

{ "scripts": { "dev": "npx -y kirbyup src/index.js --watch src --watch libs", "build": "npx -y kirbyup src/index.js" }, "devDependencies": { "kirbyup": "latest" } }

Using kirbyup 3.0.1 and Kirby 4.0.0-beta.2 how can i enable source maps to help with debugging?
Not a vite user so a bit lost here. I tried to force enable them by creating a kirbyup.config.js file in my plugin root.

import { defineConfig } from "kirbyup/config";

export default defineConfig({
	extendViteConfig: {
		build: {
			sourcemap: true,
		},
	}
});

Using sourcemap: true Chrome tries find a the sourcemap at /media/plugins/index.js.map which returns a 404.
Using sourcemap: "inline" Chrome tries to decode a DataURL which fails.

Am i missing any steps on how to do this?