Generates this message
The "buildStart" hook used by the output plugin delete is a build time hook and will not be run for that plugin. Either this plugin cannot be used as an output plugin, or it should have an option to configure it as an output plugin

Using rollup-plugin-delete with vite in vscode i have the following complaint:

Argument of type '({ mode }: ConfigEnv) => { plugins: (Plugin_2 | Plugin_2[] | Plugin | null)[]; optimizeDeps: { include: string[]; }; resolve: { extensions: string[]; alias: { 'vue-i18n': string; vue: string; }; }; build: { ...; }; server: { ...; }; }' is not assignable to parameter of type 'UserConfigExport'.
Type '({ mode }: ConfigEnv) => { plugins: (Plugin_2 | Plugin_2[] | Plugin | null)[]; optimizeDeps: { include: string[]; }; resolve: { extensions: string[]; alias: { 'vue-i18n': string; vue: string; }; }; build: { ...; }; server: { ...; }; }' is not assignable to type 'UserConfigFn'.
Type '{ plugins: (Plugin_2 | Plugin_2[] | Plugin | null)[]; optimizeDeps: { include: string[]; }; resolve: { extensions: string[]; alias: { 'vue-i18n': string; vue: string; }; }; build: { ...; }; server: { ...; }; }' is not assignable to type 'UserConfig | Promise'.
Type '{ plugins: (Plugin_2 | Plugin_2[] | Plugin | null)[]; optimizeDeps: { include: string[]; }; resolve: { extensions: string[]; alias: { 'vue-i18n': string; vue: string; }; }; build: { ...; }; server: { ...; }; }' is not assignable to type 'UserConfig'.
Types of property 'plugins' are incompatible.
Type '(Plugin_2 | Plugin_2[] | Plugin | null)[]' is not assignable to type 'PluginOption[]'.
Type 'Plugin_2 | Plugin_2[] | Plugin | null' is not assignable to type 'PluginOption'.
Type 'Plugin' is not assignable to type 'PluginOption'.
Type 'Plugin' is not assignable to type 'Plugin_2'.
Types of property 'resolveId' are incompatible.
Type 'ObjectHook<(this: PluginContext, source: string, importer: string | undefined, options: { custom?: CustomPluginOptions | undefined; isEntry: boolean; }) => ResolveIdResult | Promise<...>, {}> | undefined' is not assignable to type 'ObjectHook<(this: PluginContext, source: string, importer: string | undefined, options: { assertions: Record<string, string>; custom?: CustomPluginOptions | undefined; ssr?: boolean | undefined; isEntry: boolean; }) => ResolveIdResult | Promise<...>, {}> | undefined'.
Type '(this: PluginContext, source: string, importer: string | undefined, options: { custom?: CustomPluginOptions | undefined; isEntry: boolean; }) => ResolveIdResult | Promise<...>' is not assignable to type 'ObjectHook<(this: PluginContext, source: string, importer: string | undefined, options: { assertions: Record<string, string>; custom?: CustomPluginOptions | undefined; ssr?: boolean | undefined; isEntry: boolean; }) => ResolveIdResult | Promise<...>, {}> | undefined'.
Type '(this: PluginContext, source: string, importer: string | undefined, options: { custom?: CustomPluginOptions | undefined; isEntry: boolean; }) => ResolveIdResult | Promise<...>' is not assignable to type '(this: PluginContext, source: string, importer: string | undefined, options: { assertions: Record<string, string>; custom?: CustomPluginOptions | undefined; ssr?: boolean | undefined; isEntry: boolean; }) => ResolveIdResult | Promise<...>'.
The 'this' types of each signature are incompatible.
Type 'PluginContext' is missing the following properties from type 'PluginContext': emitAsset, emitChunk, getAssetFileName, getChunkFileName, and 2 more.

When I remove the usage of rollup-plugin-delete the message is gone

Attached a vite.config.ts file
vite.config.ts.txt

This bug is about the library type definition.

The steps to reproduce the bug are:

1. Create a Rollup based-project.
2. Install the library.
3. Add the library to the plugins' list.
4. Try to remove a single folder as following the documentation.

import remove from 'rollup-plugin-delete';

remove({
  targets: 'dist/*'
});

The expected behavior was to not have any TypeScript warning. Notice that Rollup will succeed at removing things with the plugin. It is just a TypeScript warning that has no effect on the final transpilation as Rollup will not use tsc to execute the file rollup.config.ts and the extension is here mostly for VSCode to catch most of the errors.

{
  "scripts": {
    "build": "rollup -c rollup.config.ts"
  }
}

Here is a screenshot.

Environment:

• Node Version: 11.10.0
• Lib version: 0.2.1
• TypeScript version: 3.3.3333

My guess is that the current type definition file has not been updated with the new features added recently to the lib.

EDIT: my bad... I didn't install the @types/rollup-plugin-delete. Somehow it did try to use a cached version of the definition type. Maybe there is something to dig in there.

There is currently no way to use the force option from del. This is useful for remove parents files/folders for instance.

This results in deletion of css files even though it is specifically excluded:
del({ targets: ['dist/*', '!dist/**/*.css']}),
Might this be a bug?

More of a discussion to make this issue searchable.
I don't think that the code fix is needed since it can be fixed with a configuration change.
The issue is most likely due to del upgrade in v2 and yarn PnP being an edge case that adds to the complexity

The error is this:

[!] (plugin delete) TypeError: Cannot destructure property 'withFileTypes' of '(intermediate value)(intermediate value)(intermediate value)' as it is null.
TypeError: Cannot destructure property 'withFileTypes' of '(intermediate value)(intermediate value)(intermediate value)' as it is null.
    at PosixFS.readdirPromise

TLDR Solution if you have nested folder structure in your targets:
Change the targets to ["dist/**/*", "dist/*"] (note the order)

Reproduction repository with more background info

With the following config object:

{
  targets: 'foo/**',
  ignore: 'foo/bar',
}

According to the glob docs, foo/bar and files inside it should not be deleted, but they are. I also tried ignore: 'foo/bar/**' and even ignore: [ 'foo/bar', 'foo/bar/**' ] but the issue remains.

Adding dryRun: true, by the way, does not list foo/bar or the files inside it. Running with verbose: true and without dryRun does list foo/bar and the files inside it.

Hello and thanks for this plugin. I am quite new to rollup in general so maybe I don't fully understand how to use it. I have a target directory "build" and want to clear this directory before the actual build starts. For this I want to use your plugin. My rollup.config looks like this:

import resolve from '@rollup/plugin-node-resolve';
import copy from 'rollup-plugin-copy';
import del from 'rollup-plugin-delete'

export default {
	input: 'src/my-app.js',    
	output: {
		dir: 'build/src',
		format: 'es',
	},
	plugins: [
		del({ targets: 'build/*' }),

		resolve(),
		
		copy({
			targets: [
				{ src: 'index.html', dest: 'build' },
				...
			]
		})
	]
};

This doesn't work, however, because there seems to be a conflict between deleting and building/copying. This is the output:

src/my-app.js → build/src...
[!] (plugin delete) Error: EBUSY: resource busy or locked, rmdir 'C:...\wwwroot-dev\build\src'
Error: EBUSY: resource busy or locked, rmdir 'C:...\wwwroot-dev\build\src'

I must be missing something. How is this supposed to work?

Is there a way to clean up empty folders after the plugin ran?

Ill fork this and take up the maintenance if not.

Is it possible to run this plugin only at launch? Otherwise it breaks watch functionality for me.

This issue is related to a feature request. It would be nice to have a definition type (at least) for VSCode Intellisense to trigger without having to go to the GitHub page (when using it, people will still go here to follow the installation instructions and get more informations of course).

It would be even greater if the code was written in TypeScript (but that is not necessary as an index.d.ts is enough with { "types": "./index.d.ts" } in package.json in order to trigger the Intellisense).

The solution I would like to be implemented should follow these guidelines:

• A index.d.ts at the root of this project with the necessary declaration instruction related to TypeScript.
• A "types" key in the package.json with the value of "index.d.ts" (or the path to that file if it is in a directory) for VSCode & TypeScript Intellisense to trigger automatically.

Alternatives would be to create a package and push the type definition file to @types/rollup-plugin-delete. I am not a big fan of that solution as it may require to maintain an entire new repository (I guess, never had the opportunity to try) and it seems a little overkill to have to use npm install --save-dev rollup-plugin-delete @types/rollup-plugin-delete since the type definition file should not be large.

Another alternative would be to (re?)write the project using TypeScript. Since TypeScript is just a superset of JavaScript, this should not be hard to implement and would probably only require the adding of types to function parameters and variables.

I was getting TS2349 when editing my project's vite.config.ts related to the exported default del function.

We have forked this project into kineticcafe/rollup-plugin-delete and released it as @kineticcafe/rollup-plugin-delete.

The main changes are:

1. Port to Typescript
2. Make it ESM-only (I consider this a minor failure, but I could not figure out the correct incantations)
3. Use vitest instead of jest
4. Update all the dependencies
5. Use GitHub Actions instead of Travis

We are happy to contribute these changes back upstream and retire our repository, but wanted to raise visibility and thank you for work that was easy to port. Aside from some renames and different imports, we were able to reuse all of the tests‡.

‡ We did have to make one configuration change to prevent the use of workers / threads by vitest, which is the default, because process.chdir is not thread-local.

Hi there,

This feature request is about the verbosity parameter.

The current behavior is that deleted files and folders are counted.

I think this would be good to have another level of verbosity where the names of the files & folders are enumerated as well. Especially on small to medium projects where enumerating deleted files & folders is both reassuring & not too overwhelming in the terminal.

What do you think?